SEO – Do’s and Don’ts

Do’s

  • Ensure to provide unique content for the users. Developing content just for the sake of populating your web page is a poor strategy. Make sure that your content gives a fresh perspective about the subject matter.
  • Perform a keyword research to find out the exact words that are used by people to search for your topic. There are several generalized keywords pertaining to the type of industry you belong to and it is very important to make your content identifiable as soon as those keywords are used by the users. Use the main keywords in the title, body, image tags and meta description.
  • Maintain the accessibility for the users all across your website. Design a good layout for your website, preferably hierarchical, provide Search box for efficient site navigation and most important keep a homepage that is simple and easily accessible.
  • Label or tag all the media that you insert on your website. It helps the Search Engines to decipher the non-text data as a valid content on your website and it looks professional and more appealing to the users.
  • Build internal links to connect best pieces of your content in the website. Also, try getting maximum back-links from reputed and relevant websites in the industry, which helps in validating the ingenuity and increases the visibility of your content across the digital platform.
  • Include “breadcrumbs” like previous-next buttons. This aids user-ability and makes the content Search engine friendly. Use URLs that use canonicalization as these help in effectively segregate the contents of the website.
  • Earn social credits through Social media distribution. Have social media links to Facebook, Twitter, Google+, LinkedIn etc. on your website content. Provide Share option at the bottom of your website allowing users to share your content and make sure to watermark the company’s footprint across all your content for copyright issues.

Don’ts

  • Don’t spend money on bots to artificially share your content. They are easily identifiable by the Search Engines and can incur penalties which may negatively affect your rankings.
  • Don’t recreate duplicated content. There are several tools to identify plagiarized content and this may adversely impact your Search Engine ratings.
  • Don’t provide link to every single page from your homepage as this overloads the page too much and slows it down. It can also hurt your SEO ratings.
  • Don’t use irrelevant links on your website just for the sake of it. Have links that are genuinely related to the content of your website.
  • Don’t do keyword stuffing. Google is smart enough to recognize that and might penalize your site for doing it.
  • Don’t use misleading titles and tagging. Keep it as direct as possible to increase optimization capabilities of the website.
  • Don’t overcrowd your website with back-links. Don’t get links from pages that have too many external links. Too many external links shows that the website quality is not high.

 

seo-dos-and-donts-best-practices-infographic.png

How Search Engine Works?

Search engines perform several activities in order to deliver search results.

  • Crawling – Process of fetching all the web pages linked to a website. This task is performed by a software, called a crawler or a spider (or Googlebot, in case of Google).
  • Indexing – Process of creating index for all the fetched web pages and keeping them into a giant database from where it can later be retrieved. Essentially, the process of indexing is identifying the words and expressions that best describe the page and assigning the page to particular keywords.
  • Processing – When a search request comes, the search engine processes it, i.e. it compares the search string in the search request with the indexed pages in the database.
  • Calculating Relevancy – It is likely that more than one page contains the search string, so the search engine starts calculating the relevancy of each of the pages in its index to the search string.
  • Retrieving Results – The last step in search engine activities is retrieving the best matched results. Basically, it is nothing more than simply displaying them in the browser.

Search engines such as Google and Yahoo! often update their relevancy algorithm dozens of times per month. When you see changes in your rankings it is due to an algorithmic shift or something else outside of your control.

Although the basic principle of operation of all search engines is the same, the minor differences between their relevancy algorithms lead to major changes in results relevancy.

Search box on google search results

flipkart.png

 

Look at the above screenshot, if you search for ‘flipkart’ on google you will be seeing a search box where you can search anything inside flipkart website, which could improve the site visits, which opens up a chance for more and more profits and transactions especially on a e-commerce website. How to do it? Pretty simple, just add the below script tag on header portion, everything else will be taken care of google crawler.

 

{
“@context”: “http://schema.org”,
“@type”: “WebSite”,
“url”: “https://www.yourwebsite.com/”,
“potentialAction”: [{
“@type”: “SearchAction”,
“target”: “https://www.yourwebsite.com/search?keyword={search_term_string}”,
“query-input”: “required name=search_term_string”
},{
“@type”: “SearchAction”,
“target”: “android-app://your-app-url/search/?keyword={search_term_string}”,
“query-input”: “required name=search_term_string”
}]
}

Note: Remember you should have a valid search url (functionality) already present on your website/app for this purpose, else you need to add one.

Javascript – Object watch (on all browsers)

Javascript’s object.watch is a function which tends to work only on Firefox.. How do we make it work on other browsers? Below is the code snippet to achieve this:-

 

Common JS Snippet for making object.watch to work on all browsers

if (!Object.prototype.watch) {
Object.defineProperty(Object.prototype, “watch”, {
enumerable: false
, configurable: true
, writable: false
, value: function (prop, handler) {
var
oldval = this[prop]
, newval = oldval
, getter = function () {
return newval;
}
, setter = function (val) {
oldval = newval;
return newval = handler.call(this, prop, oldval, val);
}
;

if (delete this[prop]) { // can’t watch constants
Object.defineProperty(this, prop, {
get: getter
, set: setter
, enumerable: true
, configurable: true
});
}
}
});
}

// object.unwatch
if (!Object.prototype.unwatch) {
Object.defineProperty(Object.prototype, “unwatch”, {
enumerable: false
, configurable: true
, writable: false
, value: function (prop) {
var val = this[prop];
delete this[prop]; // remove accessors
this[prop] = val;
}
});
}

 

Code Example:-

//Create an object and assign a initial value

var my_object = { blog_name:  “selvaonrails.wordpress.com” };

//Adding listener (watcher)

my_object.watch(‘blog_name‘, function (id, oldval, newval) {
console.log(‘my_object.’ + id + ‘ changed from ‘ + oldval + ‘ to ‘ + newval);
return newval;
});

Now changing the value of blog_name will print the console statement:-

my_object.blog_name=”SelvaOnRails”

Angular JS Best Practices

1. Create one directive per file
2. Create one controller per file
3. Create one service per file
4. Have only routes and general usablility code on app.js
5. Don’t ever user $rootScope, rather make use of Angular services
6. Prefer Restangular for complex API calls, $http for simple API calls, avoid $resource.
7. Don’t use {{ }} on view files, rather use either ng-bind (or) data-prefixed version
8. Use native for loops than angular.forEach
9. Only for a small storage purpose go for $cookieStore, for storing medium and large informations use $localStorage or $sessionStorage according to the need

NAMING CONVENTIONS

UpperCamelCase for Controllers and constructor Services, lowerCamelCase everywhere else.

Controllers

The naming of the controller is done using the controller’s functionality (for example shopping cart, homepage, admin panel) and the substring Ctrl in the end. The controllers are named UpperCamelCase (HomePageCtrl, ShoppingCartCtrl, AdminPanelCtrl, etc.).

Directives

Name your directives with lowerCamelCase.

Filters

Name your filters with lowerCamelCase.

Services

Use camelCase to name your services.

  • UpperCamelCase (PascalCase) for naming your services, used as constructor functions
  • lowerCamelCase for all other services.

Note that Services always return singletons. Unless you create a special service to return a newed object each time it gets called–in this case, and only in this case should you use PascalCase naming.

DIRECTORY STRUCTURE

root-app-folder
├── index.html
├── scripts
   ├── controllers
      └── main.js
      └── ...
   ├── directives
      └── myDirective.js
      └── ...
   ├── filters
      └── myFilter.js
      └── ...
   ├── services
      └── myService.js
      └── ...
   ├── vendor
      ├── angular.js
      ├── angular.min.js
      ├── es5-shim.min.js
      └── json3.min.js
   └── app.js
├── styles
   └── ...
└── views
    ├── main.html
    └── ...


THINGS TO REMEMBER

Initialization

  • One should try and place the <script> tag including the angular.js and related angular scripts at the bottom of the page to improve the app load time. This is because the HTML loading would then not be blocked by loading of angular.js and related scripts.

Expressions

  • Complex javascript code should be made as a method in the controller (added as a method to the $scope) and then, should be called from the view. This is unlike putting the complex Javascript code as Angular expressions, right, in the view.

Controllers

  • With real applications, one should avoid creating controllers in the global scope. Rather, one should use “.controller” method of the Angular Module to work with $scope object. Take a look at the sample code below illustrating this point:

Controller defined in the Global Scope:

function HelloController( $scope ) { 
      $scope.name = "Guest";
}
  • The controllers should only be used to setup initial state of the $scope object and add one or more behaviour to this object. One should avoid using controllers to do some of the following:
    • Manipulate DOM,
    • Format input,
    • Filter output,
    • Share code or state across different controllers
    • Manage the life-cycle of other components (for example, to create service instances)
  • A controller should contain only the business logic needed for a single view. The functionality should rather be moved to services and these services should be injected into the controllers using dependency injection.
  • The recommended way to declare the controller function is to use the array notation such as following because it protects against minification.

Controller defined using “.controller” method (Recommended way)

var helloApp = angular.module( "helloApp", [] ); 
helloApp.controller( "HelloController", function($scope){ 
$scope.name = "Guest"; 
});

 

  • While writing unit tests for controllers, one of the recommended ways is to inject $rootScope & $controller. Take a look at the sample unit tests on this page: http://hello-angularjs.appspot.com/angularjs-unit-test-code-example-1. The following is the sample code representing injection of $rootScope and $controller objects.
    beforeEach( 
    inject( 
    function( $rootScope, $controller ){ 
    scopeMock = $rootScope.$new(); 
    $controller( 'CompanyCtrl', {$scope: scopeMock} ); 
    })
    );

Directives

  • One should prefer using the dash-delimited format (e.g. ng-model for ngModel). While working with an HTML validating tool, one could instead use the data-prefixed version (e.g. data-ng-model for ngModel).
  • Prefer using directives via tag name and attributes over comment and class names. Doing so generally makes it easier to determine what directives a given element matches.
  • While creating directives, it is recommended to prefix your own directive names to avoid collisions with future standard.

Template

  • With large templates (HTML content with Angular directives) within an HTML file, it is recommended to break it apart into its own HTML file and load it with the templateUrl option.

Dependency Injection

The preferred way of injecting the dependencies is by passing the dependency to the constructor function rather than using one of the following other ways. In this way, the responsibility of creating the dependency object lies with other objects or function. This is straight forward for those who have worked with one or more dependency injection framework in the past. However, this could be useful information for the beginners. Following are other ways of doing dependency injection in Angular:

  • Create it using the new operator.
  • Look for it in a well-known place, also known as a global singleton.
  • Ask a registry (also known as service registry) for it.

Also Refer : https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md

 

 

Always use Restangular instead of $resource or $http

Advantages of Restangular over $http

  • It uses promises. Instead of doing the “magic” filling of objects like $resource, it uses promises.
  • You can use this in $routeProvider.resolve. As Restangular returns promises, you can return any of the methods in the $routeProvider.resolve and you’ll get the real object injected into your controller if you want.
  • It doesn’t have all those $resource bugs. Restangular doesn’t have problem with trailing slashes, additional : in the URL, escaping information, expecting only arrays for getting lists, etc.
  • It supports all HTTP methods.
  • It supports ETag out of the box. You don’t have to do anything. ETags and If-None-Match will be used in all of your requests
  • It supports self linking elements If you receive from the server some item that has a link to itself, you can use that to query the server instead of writing the URL manually.
  • You don’t have to create one $resource object per request. Each time you want to do a request, you can just do it using the object that was returned by Restangular. You don’t need to create a new object for this.
  • You don’t have to write or remember ANY URL. With $resource, you need to write the URL Template. In here, you don’t write any urls. You just write the name of the resource you want to fetch and that’s it.
  • It supports nested RESTful resources. If you have Nested RESTful resources, Restangular can handle them for you. You don’t have to know the URL, the path, or anything to do all of the HTTP operations you want.
  • Restangular lets you create your own methods. You can create your own methods to run the operation that you want. The sky is the limit.
  • Support for wrapped responses. If your response for a list of element actually returns an object with some property inside which has the list, it’s very hard to use $resource. Restangular knows that and it makes it easy on you. Check out https://github.com/mgonto/restangular#my-response-is-actually-wrapped-with-some-metadata-how-do-i-get-the-data-in-that-case
  • You can build your own URLs with Restangular objects easily. Restangular lets you create a Restangular object for any url you want with a really nice builder.

$http – $http is built into Angular, so there’s no need for the extra overhead of loading in an external dependency. $http is good for quick retrieval of server-side data that doesn’t really need any specific structure or complex behaviors. It’s probably best injected directly into your controllers for simplicity’s sake.

$resource – $resouce is good for situations that are slightly more complex than $http. It’s good when you have pretty structured data, but you plan to do most of your crunching, relationships, and other operations on the server side before delivering the API response. $resource doesn’t let you do much once you get the data into your JavaScript app, so you should deliver it to the app in its final state and make more REST calls when you need to manipulate or look at it from a different angle. Any custom behavior on the client side will need a lot of boilerplate.

Restangular – Restangular is a perfect option for complex operations on the client side. It lets you easily attach custom behaviors and interact with your data in much the same way as other model paradigms you’ve used in the past. It’s promise-based, clean, and feature-rich. However, it might be overkill if your needs are basic, and it carries along with it any extra implications that come with bringing in additional third-party dependencies.