What every Web Developer should know about SEO

#1

Post by tosbourn » Mon, Jan 12, 2015, 1:28 PM UTC

What every Web Developer should know about SEO
polemicdigital.com

Re: What every Web Developer should know about SEO

#2

Post by EC1 » Mon, Jan 12, 2015, 2:37 PM UTC

This is also a pretty good set of guidelines by Google to follow: http://static.googleusercontent.com/media/www.google.com/en/...

Re: What every Web Developer should know about SEO

#3

Post by rcarrigan87 » Mon, Jan 12, 2015, 2:49 PM UTC

If you want to see how Google ranks your site speed and user friendliness check out google page speed insights. Very handy tool for guidance on what's slowing down your site.

A constantly updated and properly marked up site map is also good to have.

Re: What every Web Developer should know about SEO

#4

Post by deanclatworthy » Mon, Jan 12, 2015, 2:49 PM UTC

This is all basic stuff, but won't affect your rankings that much. Yes, everyone should have it in place, but doesn't represent the state of SEO.

What you should know about SEO, is that it's all about getting organic links to your content, and having content that has a semantic connection to the keywords being searched for.

Re: What every Web Developer should know about SEO

#5

Post by mootothemax » Mon, Jan 12, 2015, 2:53 PM UTC

For JavaScript-heavy sites, I still recommend following Google's AJAX-crawling guidelines, and supporting the pre-rendered view request variable _escaped_fragment_

https://developers.google.com/webmasters/ajax-crawling/docs/...

You can do a good enough job by sending such requests to a PhantomJS instance, waiting for the page to load, outputting the PhantomJS-rendered HTML to the browser, and saving the HTML to a cache for faster access next time.[1]

There are also plenty of SaaS apps that will handle the pre-rendering for you.

An additional bonus of doing this is that you can intercept requests from engines and services that don't support _escaped_fragment (e.g. Facebook external hit), and always ensure that you serve pre-rendered HTML to them. (e.g. by matching on the user-agent string).

[1a] One potential hitch is knowing when a page has finished rendering. You could potentially set a variable in your code and have PhantomJS wait for that.

[1b] One other hitch is that it's possible for PhantomJS to time out e.g. waiting for an external JS library to load. It's sensible to check that your HTML output looks vaguely sane before sending to the browser (e.g. for Angular, make sure there are no {{ }} blocks in the HTML), and sending a temporary error code if something looks odd.

Re: What every Web Developer should know about SEO

#6

Post by josefresco » Mon, Jan 12, 2015, 2:56 PM UTC

Some additional info...

1. Don't let the new HTML5 tags distract or confuse you. Google knows how to deal with traditional DIVs so only use the new tags (example: SECTION, ASIDE) if you know how to properly implement.

2. Maintainability is a big one for page speed optimizations. You can easily get 95% there but that remaining 5% often comes at the expense of maintenance, and the ability to see/make changes easily.

3. Can't agree more with the section on redirects. 301's are often forgotten and can cause issues down the road with SEO and site functions.

4. The last tip I would add would be to monitor 404/access logs. Often times they will reveal SEO problems.

Re: What every Web Developer should know about SEO

#7

Post by gildas » Mon, Jan 12, 2015, 2:58 PM UTC

mootothemax wrote: post #5

For JavaScript-heavy sites, I still recommend following Google's AJAX-crawling guidelines, and supporting the pre-rendered view request variable _escaped_fragment_ https://developers.google.com/webmasters/ajax-crawling/docs/... You can do a good enough job by sending such requests to a PhantomJS instance, waiting for the page to load, outputting the PhantomJS-rendered HTML to the browser, and saving the HTML to a cac…

Another additional bonus of doing that is that you can serve "true" 404 pages (i.e. not soft 404) for invalid URLs when the page is requested with the _escaped_fragment_= query parameter.

Re: What every Web Developer should know about SEO

#8

Post by mootothemax » Mon, Jan 12, 2015, 2:59 PM UTC

josefresco wrote: post #6

Some additional info... 1. Don't let the new HTML5 tags distract or confuse you. Google knows how to deal with traditional DIVs so only use the new tags (example: SECTION, ASIDE) if you know how to properly implement. 2. Maintainability is a big one for page speed optimizations. You can easily get 95% there but that remaining 5% often comes at the expense of maintenance, and the ability to see/make changes easily. 3.…

Maintainability is a big one for page speed optimizations. You can easily get 95% there but that remaining 5% often comes at the expense of maintenance, and the ability to see/make changes easily.

Agreed. You might be able to gain a percentage point by inlining some vital CSS rules, but without hellish attention to details, that way madness lies.

Re: What every Web Developer should know about SEO

#9

Post by alphadevx » Mon, Jan 12, 2015, 3:02 PM UTC

I'm coming to the conclusion that SEO does not matter anymore, at least not this basic stuff as everyone is doing this, including your rivals, so it is really not going to get you to stand out from the crowd.

Search engines make their money from advertising your site, _not_ from sending you free traffic via SEO. So fire up your credit card and buy some Adwords in key search terms for your business, that's want they want from you. I believe we are already in the post-SEO age of the Internet, maybe we have been for a few years now.

Re: What every Web Developer should know about SEO

#10

Post by mootothemax » Mon, Jan 12, 2015, 3:03 PM UTC

gildas wrote: post #7

mootothemax wrote: post #5

For JavaScript-heavy sites, I still recommend following Google's AJAX-crawling guidelines, and supporting the pre-rendered view request variable _escaped_fragment_ https://developers.google.com/webmasters/ajax-crawling/docs/... You can do a good enough job by sending such requests to a PhantomJS instance, waiting for the page to load, outputting the PhantomJS-rendered HTML to the browser, and saving the HTML to a cac…

Another additional bonus of doing that is that you can serve "true" 404 pages (i.e. not soft 404) for invalid URLs when the page is requested with the _escaped_fragment_= query parameter.

Another additional bonus of doing is that you can serve "true" 404 pages (i.e. not soft 404) for invalid URLs when the page is requested with the _escaped_fragment_= query parameter.

For one of our sites, the Angular router redirects the user to a "true" 404 page if the in-app page cannot be found, along with the troublesome URL.

For example:

https://example.com/products/name-does-not-exist/

Will do a JS redirect to:

https://example.com/not-found/?url=/products/name-does-not-e...

The /not-found/ URL serves a "true" 404 response.

We're still in early days, and have very little data to back up the pros or cons of doing it this way.

All I can say with any certainty is that for the several months now we have zero "soft" 404s listed in Webmaster Tools.