Google Algorithms Explained, Part 1: Don’t Be Spam

This article is part of an SEO series from WooRank. Thank you for supporting the partners who make SitePoint possible.

In the SEO world, Google algorithm updates are big news. They often have a big impact for sites that can be felt for months, or in some cases, years later. But for those who don’t spend a lot of time on SEO, or are new to the industry, keeping track of every algorithm can get pretty confusing — they have funny names and it’s not always clear what each one does. Lucky for you, in this article we’ll go over the major Google algorithms, what they do and how you can avoid incurring the wrath of a panda, penguin or hummingbird.

But first, what do we mean when we say "algorithm"? To boil down the Wikipedia definition, an algorithm is “a computer’s way of figuring out which steps to take to complete a task.” In Google’s instance, its algorithms decide what steps it takes to find pages relevant to keywords used in a search, and in what order it should display those pages.

PageRank is part of the original core of Google’s search algorithm, and is considered a big factor that differentiated Google from its early competitors such as Lycos and AltaVista. Developed in the ‘90s by Larry Page and Sergey Brin, this algorithm works to determine the importance of a page or domain by counting and evaluating the links pointing at it, and then giving it a relative score between 0 and 10.

It operates based on the idea that links operate as endorsements of a page, domain or content, so the more links a page has, the better it is. According to Google:

PageRank works by counting the number and quality of links to a page to determine a rough estimate of how important it is. The underlying assumption is that more important websites are likely to receive more links from other websites.

So if you spend a lot of time working on link building, or a lot of time dealing with emails from people looking for links, you have PageRank to thank.

Note that Google used to provide PageRank as part of Google Toolbar, but stopped updating it years ago and finally removed it entirely in 2016. However, that doesn’t mean PageRank stopped being important. Links are still one of the top ranking factors.

Panda

What Is Panda?

In the old days, websites could consistently publish lots of short articles (just a few hundred words or less) with links pointing back to their site (often using exact match anchor text) across numerous article websites that would accept submissions, many without even looking at the quality of the content. The trick was to slightly change longer pieces and republish them (a process known as article spinning) or even blatantly plagiarize content in an attempt to appear at the top of search results. These websites were called "content farms" and could rank very well. The problem, from Google’s perspective, was that these websites didn’t help users find what they were looking for. They damaged Google’s user experience. Introduced in February 2011, Google’s Panda update was essentially a filter applied to search results to weed out those sites with low quality content. How does Google define low quality?

• Thin: Research has shown that Google likes long content: the average page ranked in the top ten search results has almost 2,000 words. Of course that number isn’t some sort of requirement, but what it means is that the Panda algorithm is looking for content that has enough depth to provide its users with the most information or best experience.
• Duplicate: There’s not really a "duplicate penalty" from Panda, but publishing the same content as other sites, or publishing the same thing on multiple pages across your own site, will still significantly impact your ability to rank. If your content is similar enough, you run the risk of being left out of search results altogether.

• Over-Optimized: A big part of the problem with pre-Panda content was that many of those content farms published articles that were obviously written to help the linked pages to rank for certain keywords. That meant high keyword and synonym density with low user friendliness and usefulness.

The results were noticeable, to say the least. Here’s traffic for one site that got hit by Panda:

Yikes.

Avoiding Panda Problems

So how do you stay on Google’s good side when it comes to content? Well, the obvious answer is to publish quality content. A good content strategy is to focus on publishing evergreen content, which by definition is high quality, in-depth and adds value for visitors. Not everything you publish will gain enough traction to truly become evergreen, but following the evergreen content guide will help you create in-depth, unique and naturally optimized articles that generally rank well.

However, just being a good writer is not always enough. Depending on what type of site you have, you could have a problem with duplicate content and not even know it. This is particularly common with content management systems, syndicated content, e-commerce shopping cart systems, international sites, search/filter features and pagination. You’ll have to use some technical know-how to deal with these types of duplicate content issues.

Penguin

What Is Penguin?

Since links have always been such an important part of ranking in Google SERPs, SEOs have spent a lot of time and effort developing ways to build links. Even though PageRank took linking domain quality into account when scoring a page, building a huge number of lower quality links could very quickly add up and surpass sites that had links from fewer, better sites. This resulted in some link building techniques that were slightly less than white hat:

Continue reading %Google Algorithms Explained, Part 1: Don’t Be Spam%

by Sam Gooch via SitePoint

Hey, Students! Save 50% on a Yearly Envato Tuts+ Subscription

Brando

by Rob Hope via One Page Love

Getting Started With Paper.js: User Interaction

AtoZ CSS Quick Tip: Solving Common CSS Problems

Q is for Questions about CSS

There is literally nothing else to say on the topic of CSS quotes, nor is there any other selector, property or value that starts with Q. So, in this week’s tips, I answer some common questions I get from my students, AtoZ supporters and fellow professionals.

How do you center things vertically in CSS?

I get this one a lot. And I get this one in addition to the more general question of how to horizontally center things in CSS which I addressed in an earlier tip all about floats.

On the topic of vertical centering, some people will tell you it’s really difficult. But these days it doesn’t require much CSS and can be done on any element - even in a responsive project when you don’t know how wide or tall the container or the element to be centered is.

Take the following HTML which marks up a simple .modal message box inside of a container:

[code language="html"]
<div class="modal">
<h2>Message title</h2>
<p>Message text lorem ipsum dolor sit amet</p>
</div>
[/code]

To absolutely center the .modal element we can combine absolute positioning with translate.

Step one is to put the top left corner of the box right in the center of the parent container - which we can do by offsetting its top and left edges by 50% of the height and 50% of the width of the parent container:

[code language="css"]
.container {position: relative; width: 100vw; height: 100vh;}
.modal {position: absolute; top: 50%; left: 50%;}
[/code]

Step two is to bring the element back into the absolute center of the container. We need to move it back by half of its width and up by half of its height.

If we know the dimensions of the .modal we can achieve this with some negative margin and divide the width or height by 2 to get the required value. But if the .modal is likely to change size (due to being sized with percentages for example) this won’t work.

Instead, using a translate transformation, we can move the element by a percentage of its existing size.

[code language="css"]
.modal {position: absolute; top: 50%; left: 50%;}
/* back by half its width, up by half its height */
transform: translate(-50%, -50%);
[/code]

And there you have it, the element is perfectly centered even with a variable size.

Continue reading %AtoZ CSS Quick Tip: Solving Common CSS Problems%

by Guy Routledge via SitePoint

Let's Go: Testing Golang Programs

In this tutorial I will teach you all the basics of idiomatic testing in Go using the best practices developed by the language designers and the community. The main weapon will be the standard testing package. The target will be a sample program that solves a simple problem from Project Euler.

Square Sum Difference

The sum square difference problem is pretty simple: "Find the difference between the sum of the squares of the first one hundred natural numbers and the square of the sum." 

This particular problem can be solved rather concisely especially if you know your Gauss. For example, the sum of the first N natural numbers is (1 + N) * N / 2, and the sum of squares of the first N integers is: (1 + N) * (N * 2 + 1) * N / 6. So the whole problem can be solved by the following formula and assigning 100 to N:

(1 + N) * (N * 2 + 1) * N / 6 - ((1 + N) * N / 2) * ((1 + N) * N / 2)

Well, that's very specific, and there isn't much to test. Instead, I created some functions that are a little more general than what's needed for this problem, but can serve for other programs in the future (project Euler has 559 problems right now).

The code is available on GitHub.

Here are the signatures of the four functions:

// The MakeIntList() function returns an array of consecutive integers

// starting from 1 all the way to the `number` (including the number)

func MakeIntList(number int) []int



// The squareList() function takes a slice of integers and returns an

// array of the quares of these integers

func SquareList(numbers []int) []int



// The sumList() function takes a slice of integers and returns their sum

func SumList(numbers []int) int



// Solve Project Euler #6 - Sum square difference

func Process(number int) int

Now, with our target program in place (please forgive me, TDD zealots), let's see how to write tests for this program.

The Testing Package

The testing package goes hand in hand with the go test command. Your package tests should go in files with the "_test.go" suffix. You can split your tests across several files that follow this convention. For example: "whatever1_test.go" and "whatever2_test.go". You should put your test functions in these test files.

Every test function is a publicly exported function whose name starts with "Test", accepts a pointer to a testing.T object, and returns nothing. It looks like:

func TestWhatever(t *testing.T) {
    // Your test code goes here
} 

The T object provides various methods you can use to indicate failure or record errors.

Remember: only test functions defined in test files will be executed by the go test command.

Writing Tests

Every test follows the same flow: set up the test environment (optional), feed the code under test input, capture the result, and compare it to the expected output. Note that inputs and results don't have to be arguments to a function. 

If the code under test is fetching data from a database then the input will be making sure the database contains appropriate test data (which may involve mocking at various levels). But, for our application, the common scenario of passing input arguments to a function and comparing the result to the function output is sufficient.

Let's start with the SumList() function. This function takes a slice of integers and returns their sum. Here is a test function that verifies SumList() behaves as it should.

It tests two test cases, and if an expected output doesn't match the result, it calls the Error() method of the testing.T object. 

func TestSumList_NotIdiomatic(t *testing.T) {
    // Test []{} -> 0
    result := SumList([]int{})
    if result != 0 {
            t.Error(
                "For input: ", []int{},
                "expected:", 0,
                "got:", result)
    }

    // Test []{4, 8, 9} -> 21
    result = SumList([]int{4, 8, 9})
    if result != 21 {
            t.Error(
                "For input: ", []int{},
                "expected:", 0,
                "got:", result)
    }
}

This is all straightforward, but it looks a little verbose. Idiomatic Go testing uses table-driven tests where you define a struct for pairs of inputs and expected outputs and then have a list of these pairs that you feed in a loop to the same logic. Here is how it is done for testing the SumList() function.

type List2IntTestPair struct {
    input  []int
    output int
}


func TestSumList(t *testing.T) {
    var tests = []List2IntTestPair{
        {[]int{}, 0},
        {[]int{1}, 1},
        {[]int{1, 2}, 3},
        {[]int{12, 13, 25, 7}, 57},
    }

    for _, pair := range tests {
        result := SumList(pair.input)
        if result != pair.output {
            t.Error(
                "For input: ", pair.input,
                "expected:", pair.output,
                "got:", result)
        }
    }
}

This is much better. It is easy to add more test cases. It's easy to have the full spectrum of test cases in one place, and if you decide to change the test logic you don't need to change multiple instances.

Here is another example for testing the SquareList() function. In this case, both the input and the output are slices of integers, so the test pair struct is different, but the flow is identical. One interesting thing here is that Go doesn't provide a built-in way to compare slices, so I use reflect.DeepEqual() to compare the output slice to the expected slice.

type List2ListTestPair struct {
    input  []int
    output []int
}

func TestSquareList(t *testing.T) {
    var tests = []List2ListTestPair{
        {[]int{}, []int{}},
        {[]int{1}, []int{1}},
        {[]int{2}, []int{4}},
        {[]int{3, 5, 7}, []int{9, 25, 49}},
    }

    for _, pair := range tests {
        result := SquareList(pair.input)
        if !reflect.DeepEqual(result, pair.output) {
            t.Error(
                "For input: ", pair.input,
                "expected:", pair.output,
                "got:", result)
        }
    }
}

Running Tests

Running tests is as simple as typing go test in your package directory. Go will find all the files with the "_test.go" suffix and all the functions with the "Test" prefix and run them as tests. Here is what it looks like when everything is OK:

(G)/project-euler/6/go > go test

PASS

ok      _/Users/gigi/Documents/dev/github/project-euler/6/go    0.006s

Not very dramatic. Let me break a test on purpose. I'll change the test case for SumList() such that the expected output for summing 1 and 2 will be 7.

func TestSumList(t *testing.T) {
    var tests = []List2IntTestPair{
        {[]int{}, 0},
        {[]int{1}, 1},
        {[]int{1, 2}, 7},
        {[]int{12, 13, 25, 7}, 57},
    }

    for _, pair := range tests {
        result := SumList(pair.input)
        if result != pair.output {
            t.Error(
                "For input: ", pair.input,
                "expected:", pair.output,
                "got:", result)
        }
    }
}

Now, when you type go test, you get:

(G)/project-euler/6/go > go test

--- FAIL: TestSumList (0.00s)

006_sum_square_difference_test.go:80: For input:  [1 2] expected: 7 got: 3

FAIL

exit status 1

FAIL    _/Users/gigi/Documents/dev/github/project-euler/6/go    0.006s

That states pretty well what happened and should give you all the information you need to fix the problem. In this case, the problem is that the test itself is wrong and the expected value should be 3. That's an important lesson. Don't automatically assume that if a test fails the code under test is broken. Consider the entire system, which includes the code under test, the test itself, and the test environment.

Test Coverage

To ensure your code works, it's not enough to have passing tests. Another important aspect is test coverage. Do your tests cover every statement in the code? Sometimes even that is not enough. For example, if you have a loop in your code that runs until a condition is met, you may test it successfully with a condition that works, but fail to notice that in some cases the condition may always be false, resulting in an infinite loop. 

Unit Tests

Unit tests are like brushing your teeth and flossing. You shouldn't neglect them. They are the first barrier against problems and will let you have confidence in refactoring. They are also a boon when trying to reproduce issues and being able to write a failing test that demonstrates the issue that passes after you fix the issue.

Integration Tests

Integration tests are necessary as well. Think of them as visiting the dentist. You may be OK without them for a while, but if you neglect them for too long it won't be pretty. 

Most non-trivial programs are made of multiple inter-related modules or components. Problems can often occur when wiring those components together. Integration tests give you confidence that your entire system is operating as intended. There are many other types of tests like acceptance tests, performance tests, stress/load tests and full-fledged whole system tests, but unit tests and integration tests are two of the foundational ways to test software.

Conclusion

Go has built-in support for testing, a well-defined way to write tests, and recommended guidelines in the form of table-driven tests. 

The need to write special structs for every combination of inputs and outputs is a little annoying, but that's the price you pay for Go's simple by design approach.

by Gigi Sayfan via Envato Tuts+ Code

How to Analyze Your YouTube Marketing With Google Analytics

Do you use YouTube for business? Want to connect Google Analytics to your YouTube channel? Google Analytics can show you how people find and engage with your channel, and how YouTube drives traffic to your website. In this article, you’ll discover how to set up Google Analytics to track and measure the impact of your [...]

This post How to Analyze Your YouTube Marketing With Google Analytics first appeared on .
- Your Guide to the Social Media Jungle

by Kristi Hines via