via mashable.com
Google and Bing both have Webmaster tools that are invaluable. This is a good introduction
Thursday, May 26, 2011
Monday, May 23, 2011
Friday, May 20, 2011
Search Engines Don’t Like You? Don’t Jump To Conclusions
One of the most frustrating things about technical problems with a site is that the ways they show up in search engines are usually unexpected or subtle. What looks like a penalty can actually be a problem introduced with a new version or new feature of a website.
Because the true causes of problems like these are usually not at all obvious, they can lead to hypotheses that border on the paranoid (“Google doesn’t like my site,”) or wild speculation: (“I was put in the sandbox and then hit with Panda. I call it the Pandbox.”).
Since Google isn’t alive and doesn’t have emotions (yet), we can safely set aside (for now) any search engine anthropomorphizing and focus on finding root causes that may be lurking in the site’s technical infrastructure.
Symptoms: Fewer Pages In The Index, Drop In Long Tail Traffic
The main causes for problems with site coverage include duplicate content, allowing pages with no SEO value to be crawled, and network problems.
Duplicate content occurs when you can get to a page through multiple URLs.
Sometimes this is caused by having an entire copy of a site available on another subdomain, like http://www1.yoursite.com/, or on an IP address, like http://192.168.1.1/.
Duplicate content can also happen at the page level, when a page is available at multiple URLs like this:
- http://www.yoursite.com/category
- http://www.yoursite.com/category/
- http://www.yoursite.com/category/default.aspx
- http://www.yoursite.com/category/Default.ASPX
- http://www.yoursite.com/category/default.aspx?referral_id=1
Both types of duplicate content reduce the number of pages in the index because search engines are wasting their time crawling multiple copies of a website or a page.
Search engines throw away these extra copies because there is no point in including redundant pages in the index. This means that time spent crawling more pages on your site was wasted crawling extra copies of pages that won’t be used anyway.
For the example pages above, that site would have to be crawled at least five times to get each page of the site.
If you have a duplicate site, you can use a 301 to permanently redirect any visitors to the main site.
Fixing duplicate content at the page level is a bit tricker.
Select one canonical URL from each set of potential duplicate URLs and make sure that each duplicate URL permanently redirects to the canonical one. If this isn’t possible – for example, due to tracking parameters like referral_id=1 above – use a link rel=canonical tag that points to the canonical URL and configure Bing and Google webmaster tools to ignore the appropriate parameters.
Diagnosing Crawl Inefficiencies
Allowing pages with no value to be crawled means that the search engines are spending valuable resources crawling things like API calls, log files, or pages with an infinite number of combinations like a web calendar.
Similar to duplicate content, crawl inefficiency means that search engines are crawling useless pages, at the expense of pages that you would like crawled.
These zero-value pages aren’t going to lead to any conversions, assuming that they are even indexed by search engines or rank well for anything.
To fix these types of problems, use the robots.txt file to exclude these types of pages. Be sure to test any changes to your robots.txt file in Google Webmaster Tools before pushing them live.
Networking problems can be very elusive. Most of the networking problems I have seen involve either load balancing or DNS.
Load balancing is used on larger sites to spread web requests among a number of back end servers. Sometimes it is misconfigured in a way in which most of the crawler requests go to one backend server, which eventually slows to a crawl.
DNS problems can make a website unnecessarily slow for first time visitors or in extreme cases, make it intermittently unavailable.
You can easily check your DNS configuration with an on-line tool like IntoDNS. Checking the load balancers or other aspects of the back end network is not so easy, so it’s probably best to ask a network engineer about any recent changes to the infrastructure.
Symptoms: Wrong Pages Ranking, Decline In Ranking
These symptoms are usually caused by duplicate copies of important pages or by search engines not being able to understand the linking structure of your site.
Duplicate content can have a negative effect on ranking because inbound links to a particular page – a very important signal for search engines – are spread out among different URLs. As a result, the search engine is only aware of the number of inbound links for the one copy of the page that it decides to keep.
Make sure that all of the intended inbound links count towards the page by fixing these duplicate URLs as described above.
Another important signal for search engines is how a page is linked within a site. For example, a page with a link from the homepage will be considered a more important page than a page that is orphaned on the site with no links.
Coding site navigation elements in Flash, Silverlight, or JavaScript can make it impossible for search engines to extract these links. As a result, they are missing key information about what pages on a site are the most important.
Investigate Before You Make Assumptions
This is not a complete list of root causes for indexing issues and traffic loss, but it does contain the most common issues that I have seen with sites that I have been asked to review.
Other causes of similar symptoms are page speed, cache unfriendliness, internationalization issues, server misconfigurations, and security vulnerabilities. Each one is worthy of an article in itself.
I hope this provides some additional ideas of where to hunt down causes of particularly vexing problems with the way your site is performing in search.
Fortunately, it is much easier to redirect a duplicate copy of your site or fix a DNS misconfiguration than it is to influence Google or Bing’s algorithms.
While search engines definitely penalize some sites and it is possible for a site to get caught up in algorithm changes, make sure you have thoroughly reviewed your technical architecture before jumping to any conclusions about what search engines don’t “like” about it.
Opinions expressed in the article are those of the guest author and not necessarily Search Engine Land.
Related Entries
Related Topics: 100% Organic - Search Engine Optimization Tips
Thursday, May 19, 2011
Wednesday, May 18, 2011
FT.com / Technology - Android smartphones face data breach threat
Owners of Android smartphones are being warned to avoid public WiFi networks after researchers found a security flaw that could affect the vast majority of devices based on Google’s software.
A trio of researchers at Ulm University in Germany found that it was “quite easy” for hackers to intercept data from Google’s photo-sharing, calendar and contacts applications, as well as potentially other Google services such as Gmail, using a flaw that affects 99 per cent of all Android devices.
The revelation will again put the spotlight on Google’s approach to security with its mobile operating system, which is the most popular software for smartphones in the world. The security flaw has been fixed in Android’s 2.3.4 version of its operating softwares and beyond.
In March, Google was forced to remove more than 50 rogue applications, which could have stolen data or sent costly messages, from tens of thousands of Android devices.
The attack works when unsecured wireless access points that imitate public WiFi hot spots that the phone has accessed before – such as a coffee shop chain – capture an authentication token.
That token can then be used by attackers to access and modify personal data in Picasa, Google’s photo site, Calendar and Contacts. Business customers using Google apps on Android are not affected by the weakness because all traffic is encrypted by default.
“The implications of this vulnerability reach from disclosure to loss of personal information for the Calendar data,” said the Ulm researchers in a posting on their website.
“Beyond the mere stealing of such information, an adversary could perform subtle changes without the user noticing. For example, an adversary could change the stored e-mail address of the victim’s boss or business partners hoping to receive sensitive or confidential material pertaining to their business.”
Google said of the flaw: “We’re aware of this issue, have already fixed it for calendar and contacts in the latest versions of Android, and we’re working on fixing it in Picasa.”
However, according to the researchers, the flaw still affects devices running older versions of Android, which make up 99.7 per cent of Google smartphones in use today.
“The latest research just shows that Android users need to be even more careful with their phones than they are with their PCs,” said Omri Sigelman, vice-president of AVG Mobilation, a provider of security software for Android.
“All platforms are vulnerable to hackers, particularly at the beginning of their lives, but the openness and popularity of Android means that it is especially at risk. Sadly, many operators don’t provide the necessary updates, leaving their users vulnerable to critical flaws like this one.”
The Ulm researchers recommended that Android users turn off “automatic synchronisation” in the settings menu when connecting with open WiFi networks and let their devices “forget” wireless networks they have used previously.
“The best protection at the moment is to avoid open WiFi networks at all when using affected apps,” they wrote.
via ft.com
Monday, May 9, 2011
Sunday, May 8, 2011
6 Reasons To Use JavaScript Libraries & Frameworks
6 Reasons To Use JavaScript Libraries & Frameworks
I've seen many articles around the internet from JavaScript fundamentalists that advocate writing your own JavaScript code instead of using JavaScript frameworks like MooTools, Prototype / Scriptaculous, jQuery, MochiKit, YUI Library, and Dojo Toolkit, and I just cannot agree with their reasons for not using these spectacular frameworks.
Among other reasons, fundamentalists state:
- You don't learn the deep-down JavaScript code because you're using shortcut functions within the framework
- Javascript frameworks are bloated and contain a great amount of code you will never use
- You shouldn't make users download more than what's needed
- You shouldn't trust the code of others for your purposes (if you want it done right, do it yourself mentality)
Ridiculous. Don't listen to elitists! You SHOULD use JavaScript frameworks for the most important reasons.
Don't Reinvent The Wheel
Why write code that's already been written (better)? A good programmer is a lazy programmer, so be lazy. The tools are there -- use them.
Do More With Less Code
Most JavaScript frameworks provide function "chaining." Chaining allows you to do more with less code. Less code means less maintenance time, less download time, and less coding time. Check out MooTools chaining.
Save Time -- You Don't Code Your Own OS, Do You?
I love JavaScript as much as the next guy, but some programmers REALLY love developing JavaScript. Let the experts do the tough part, you take their work and make what you'd like of it.
Chances Are, You Aren't The Expert
As big as any programmer's ego is, there are people out there that are smarter, more inventive than you. Most Web Developers need to be a jack of all trades and it's difficult to keep up with every language when you're needed in every facet of a website's construction and launch. The minds behind the frameworks have their eyes on JavaScript daily -- trust in them.
Speed Thrills
The creators of these JavaScript frameworks have their own private pissing contest when it comes to JavaScript speed put a lot of effort into making sure their frameworks are fast. The first job of JavaScript for mass web visitor usage is to be fast -- users expect accuracy, speed is the most important part. Who's fastest today? Check out SlickSpeed.
Avoid Cryptic JavaScript Base Code
Why use JavaScript's default functions when you can use a framework's English-named functions? For example:
//standard JavaScript document.getElementbyId('mydiv').style.color = '#f00'; // camel-case the style! //mootools JavaScript $('mydiv').setStyle('color','#foo');copy//standard JavaScript document.getElementbyId('mydiv').style.color = '#f00'; // camel-case the style! //mootools JavaScript $('mydiv').setStyle('color','#foo');These are the reasons I use JavaScript frameworks. Need I say more?
Do you have more reasons? Please share them!
-->Related David Walsh Posts
Written By David Walsh
Debuted on Wednesday, September 5, 2007.
Feedback Welcome
Was this blog post helpful?
Brilliant Discussion
ktor on September 5, 2007 @ 7:53 am
7. Unified browser API, most of the time You dont have to think about browser compatibility because guys from Your framework took care (btw. I love jQuery).
Reply0
0
david on September 5, 2007 @ 8:25 am
Excellent point ktor! I don’t have every browser at my disposal but the creators of the frameworks test their code on every A-grade browser. I wonder how many “workarounds” they need to do (*cough* Internet Explorer *cough*).
Thank you for your addition!
ReplyCraig Francis on September 6, 2007 @ 3:42 am
While I agree with the reasons for using the frameworks, I have had several bad experiences:
- Just before website launch (tight deadline), the JS stopped working in a specific case, and I had no idea what the framework was doing in order to fix it.
- Quite a few frameworks rely on browser detection (userAgent), not on feature detection… this can cause issues when a new browser is launched (IE7), and you have to wait for the framework to be updated by someone else (instead of fixing your own code, which you already understand).
- Many of the frameworks trigger errors in the Firefox strict error checking mode (MooFX was, when I used it, guilty of this).
- Had a couple of cases (UFO Flash replace), which did not support the XML content type (document.write in FF1.5)… although I don’t use XML on the Live servers, its really useful in development to ensure your tags are nested/closed correctly.
- Having to use 2 or 3 frameworks as the one you originally built the site in does not have a feature another Framework provides… this really starts to increase the page size, and causes issues with over-rides on the “window.onload” etc.
- Frameworks can suddenly die… end of life, and there is no longer any more support.
But then again, I only do simple “helper” functions on websites, so I don’t really need the Frameworks… I’m sure in bigger, heavy JS sites, the Frameworks might help.
For now though, I like my JS, which has been written to be easily understood, instead of being small, fast and difficult to understand.
For some examples, see my website:
ReplyBill Goates on September 6, 2007 @ 4:41 pm
I will be the elitist then.
A good programmer is lazy, but he also knows exactly what all his code does. That includes the code of the framework he is using.
A single framework is maybe not bloated, it is if you only use one function out of it. Also a frameworks itself doesn’t do much, it provides some basic functions. For a full webapplication, you will need to include user controls and program logic. And before you know it, you created a monster using multiple frameworks and component libraries good for over half a meg of javascript files.
There is another solution. ‘Borrow’ only the few functions you actually need and understand, and slowly buildup your own library. If that’s still to much coding for you, I don’t think you should be using any frameworks or code professionally at all.
ReplyExcellent points Bill, though I disagree that frameworks shouldn’t be used professionally. Look at Apple (Prototype), Digg (Prototype), or cNet(MooTools).
If you know and understand the language thoroughly, a framework should be a great help.
Thank you for your post!
ReplyIt is my obviously failed attempt to sound elitist that went wrong, but I meant to say that if you don’t understand the code of a framework, don’t use it. And if you understand it, cut out the pieces you need.
ReplyBaz L on September 18, 2007 @ 7:29 am
I couldn’t agree more. I really agree with the lazy thing. That’s me.
Also, this “code it yourself” mentality has never really struck me and I’m glad.
If it’s done, it’s done. Especially since it’s done by a team of people concentrating on just that one thing over a period of several months.
Whereas if I were to do it, I would code something that I need in the next 20 minutes. There’s no way to put enough thought into things like that.
ReplyRob on April 26, 2010 @ 10:09 pm
I personally take a similar approach to Bill, in that I have “borrowed” and collected a small library of objects and prototype methods, which I have refined and tested over time with necessity.
The majority of the functionality I would use a framework for, I often find, can be distilled into a dozen or so prototype methods, ajax methods, cookie methods and DOM queries/manipulations. The majority of most frameworks, in my experience, is basically wasted space. The dollar sign function, for instance, is very easily reproducible.
These collected methods, in combination with my use of method chaining, and structuring my code with the module pattern, allow me to write extremely efficient, flexible and portable JavaScript.
That is not to say that a framework is not the right choice for many or most people. All claims of elitism aside, my philosophy is that if I understand 100% of my codebase, I can debug 100% of my codebase.
ReplyKieran on July 25, 2010 @ 9:05 am
My problem with frameworks is that, there are problems in them and parts arnt cover’d by all browsers. There has been a problem with jQuery and chrome AJAX for a long time, i know loads of websites that use jQuery and they will give any reason other then we cant code the JS out self. And the chrome problem is an easy fix in proper JS.
Also yes be lazy but for your laziness who is footing the bill ? the computer. the more lazy you are the more the clients computer has to work, and i for one hate slowness. Image if someone uses a phone to go on your site ? 1 page would be ok but if they start opening lots of tabs and everyone used libraries
Replyvladimir prieto on October 23, 2010 @ 4:15 pm
Mootools Chaining link isn’t right. the new link is:
http://demos111.mootools.net/Chain.Periodical
;)
Replyanthony on April 8, 2011 @ 4:02 am
There is pros and cons of the library. The simplicity and magic is that you get them all readymade on the plate instantly and mostly freely. No when you spend time to create such libraries, you need lots of time and resource to get such library.
Instead you can go through the features of some of the libraries, its coding and can decide before hand if you need to use this library. I guess there is no way that anyone can stop you from writing functionalities that are not there in the library. You can write anytime.
ReplyJoin the Discussion!
Share your thoughts without being a jerk! And wrap your code in
<code>tags, f00!
via davidwalsh.name
Learn to use a Library and Framework like JQuery or build your own library - What do you think?
Thursday, May 5, 2011
HTML5, CSS3, UX, Design: Links from An Event Apart Boston 2011 – Jeffrey Zeldman Presents The Daily Report
via zeldman.com
If some of the top people in web design met for a conference would you like to know what they talked about? Click the link.
Wednesday, May 4, 2011
Expression Studio 4 launched, wants to kill ugly apps
via arstechnica.com
Now Available FREE to Winter Park Tech students as apart or our MSDN subscription along with a LOT more software from MIcrosoft
Subscribe to:
Posts (Atom)