Build Great Backlinks has posted a new item, 'An Evergreen Content Case Study'
Posted by ChristopherFielden
This post was originally in YouMoz, and was promoted to the main blog because it
provides great value and interest to our community. The author's views are
entirely his or her own and may not reflect the views of Moz, Inc.
Creating timeless content is something all SEOs should aspire to do. Why? When
placed in front of the right audience, amazing content is highly likely to
generate ongoing interest, engagement, links, and traffic, leading to increased
sales/conversions and brand awareness. These results tend to make all but the
most difficult client quite happy.
Image by Dominic Alves
In 2012, I decided to undertake an evergreen content experiment. I created a
piece of content that I planned to update regularly over an extended period of
time. I was in this for the long haul â I wanted to keep working on this
content for at least a year. The aim was to see if putting ongoing effort into
one page on a website would prove more efficient than spending time planning and
creating multiple pieces of fresh content.
Common content performance patterns
Many creative content campaigns produce spikes of interest when they're
released and then dwindle in popularity. If you're nodding your head in
agreement, this might look familiar:
Creative campaign referral traffic spike, taken from Google Analytics
When shared, you see a brief spike in traffic, and then visits decline. This
example is taken from the release of a well-received infographic that saw a lot
of visits when it was shared on Reddit.
A spike isn't always a bad thing. At the last count, this example generated
over 35 decent quality links (ranging from DA 30 to DA 82) and thousands of
social shares. This is a good result, but I wanted to try and create something
that saw continued growth in traffic, engagement, and links over time rather
than a spike.
Evergreen experiment
So I could share the results openly without contravening any client
confidentiality agreements, I decided to conduct the test on my personal
website. I write fiction, and I originally created my website to showcase my
short stories. I launched the site in October 2011.
Image by Rose Craft
I'm not famous. No one knows who I am. No one found my writing, because no one
was searching for it. Aside from friends and family, few people read my stories.
Boo hoo.
In an attempt to gain an audience, I decided to try and make my website useful
to the short story-writing community (people who write short stories also like
to read them). I'd spent a LOT of time researching short story competitions to
enter. I'd found a few decent resources, like Booktrust, that listed some
writing competitions, but none of the lists or calendars were exhaustive or kept
very up to date, and many of them didn't list the full range of details I was
interested in (closing dates, prize money, word count limits, genres, publishing
opportunities etc).
So I decided to create an extensive short story competition list on my
website.
Research
I was fairly certain, given the amount of competition lists in print magazines
and the amount of writing websites I'd found, that there would be an audience
for this type of content. To be certain, I did some keyword research.
There was an audience. Further research showed there was a large amount of
long-tail keyword opportunities.
So I created the page, initially listing details of approximately 50 writing
contents. The list went live during April 2012.
Page content
The page format is fairly simple. I started out with two tables, one listing
regular writing competitions (monthly, quarterly, triannual and biannual) and
another listing annual contests. Over time, I've added more tables so the
resource is as easy to use as possible.
At the top of the page I openly invite users to contact me to have writing
competitions listed. I also invite users to let me know if any of my details are
incorrect, out of date, or if they find any broken links.
Use of outbound links
Again, to make the resource easy for writers to use, I've linked to all the
competitions I've listed. I've read all sorts of discussions regarding outbound
links and whether it's best for them to be follow or no-follow, as well as
discussions about how many links you should have on a page alongside concerns
about the quality of the sites you link to and whether that has any impact on
SEO.
As there doesn't seem to be a definitive right or wrong way to do this, I
decided to ignore all these concerns and just link to the most useful page on
the different competition websites for the user. The only exception is when I
link to a competition website that updates its URLs each time it updates the
competition details. In this instance I link to the homepage to avoid excessive
administration and maintenance of the page.
All links are followed.
Page maintenance
Image by Abhisek Sarda
From the day the page went live, I decided that I was going to display the
date the content was last updated prominently at the top of the page. I wanted
users and search engines to be able to see that the page was cared for and
updated regularly.
I've read many arguments against using dates. This is usually because time
constraints mean webmasters can't update content regularly and the date often
has the opposite effect, showing how out of date the content has become. But as
I knew I'd be updating the page regularly, this wasn't a concern.
I update the page at least twice a month, sometimes as frequently as twice a
week, depending on how much time I have available.
On average, one competition contacts me a week, asking to be added to the
list.
I respond to the vast majority of comments, either privately via email or as a
comment, depending on what seems most appropriate given the subject matter.
Technical notes
My website is pretty basic. From a technical standpoint, I have ensured that
the menu structures and URLs made sense and that my authorship has been setup
correctly. Aside from that, all I've done is generate content. I've purposely
kept the amount of pages on the site low, only adding new pages when I have to.
At the time of writing, the site has 36 pages.
No linkbuilding
While undertaking this experiment I haven't done any active link building at
all. Any links the website has gained have been natural. Likewise, I haven't
undertaken any outreach. I have only engaged with writers and competition
administrators that have approached me directly.
I did this to see how well the page could perform naturally, with internet
users initially finding the content via organic search. Over time, this has led
to natural interaction through comments, social sharing and links (and the
unavoidable plethora of spam comments in my inbox). But I haven't actively
pushed the content. The results have come from natural content discovery and
users outreaching to me.
Results
Traffic
This first graph shows the growth in traffic to the entire site from all
mediums since launch in October 2011:
Traffic from all mediums to entire site from October 2011 to May 2013
Below is a breakdown of the figures from the different mediums:
The second graph shows the visits from all mediums to the short story
competition page from its launch in 2012:
Traffic from all mediums to short story competition page from April 2012 to
May 2013
Since its launch, the short story competition list has accounted for 67% of
all the visits landing on my website (total entries to all pages are 77,374
â page entries to the competition page are 51,861). Full details of growth
in visits to the page from all mediums can be seen below:
Visits have increased substantially since the competition list was launched.
The dip we can see in April and May seems to be due to seasonality. The page
still ranks well for a wide variety of long-tail phrases, and the New Year and
autumn are seasonal peaks in writing-relating searches â admittedly, this
is a generalisation, but as the site only launched in 2011 I don't have a great
deal of data to work with.
If patterns follow those of last year, I'd expect to see a rise in traffic in
September.
Amount of search terms
10,728 search phrases have been used to find the page through organic search.
Most popular search terms used to find the short story competition page
Given that â(not provided)' accounts for 30% of these searches, it's
safe to assume that the figure is actually substantially higher, so there is a
lot of long-tail search involved here.
The large word count of the page copy contributes to this. At the time of
writing this post, there were 11,632 words of copy on the page, of which user
comments account for 3,463. At the time of writing this post, there are 66
comments on the page, some of them replies from me.
Social shares
The total amount of social shares to date is 127:
Details generated using Shared Count
I find that writers will often share the page on Facebook and Twitter, as will
administrators of the competitions I list, if they run social profiles. Since
the beginning of 2013, I have seen the share counts rising more rapidly, which I
would expect given the large increases in traffic the page has seen when
compared to last year.
Links
You can see details of the links that have been attracted below:
Data taken from Majestic SEO
Results from Moz's Open Site Explorer
The volume of links isn't huge. But this project is aimed at slow growth, and
I haven't actively asked anyone for a link. I want links to be entirely natural,
only coming from those who think the content is worth linking to of their own
volition. The only exception I can think of is me writing about the experiment.
As the resource becomes more widely recognised, I would expect the amount of
links to increase accordingly. Recently, I have received my first university
(.ac.uk) link, and started to receive correspondence from university lecturers
who are involved with creative writing courses, asking about writing
opportunities for their students (which led to me adding the âWriting
Competitions for Young Writers & Children' table to the page). This bodes really
well for the future, as relevant university website links are likely to help the
site's performance greatly. And this kind of natural link building should make
my backlink profile Penguin-proof long into the future.
I guess the key point here is that it's taken almost a year of developing this
content to start gaining links of this quality. Now that a handful of lecturers
have found the site and started using it, it'll be very interesting to see how
the link results fare over the next twelve months.
Hmm, I feel another blog post coming on in the not so distant futureâ
There are a couple of other points to bear in mind:
I've done this work in my spare time, around work and other commitments. If you
had the time to focus fully on projects of this nature you could probably
generate these types of results far more quickly.
The links generated have been entirely natural as I haven't actively asked
anyone for a link.
Point 2 proves that detailed, focused content can work in its own right. You
don't have to outreach and link build to see some level of success.
Does this type of content help conversions?
Due to the growth in traffic to my website, I have increased my audience and
engagement with my site. I'm beginning to be recognised as a thought leader (and
a brand, I guess) in my niche area. Users have started to approach me with all
manner of queries. I also receive frequent requests to proofread other writers'
work. If I had more time, this is a paid service I could consider offering in
the future. So producing the content has revealed business areas I could expand
into.
Ultimately, all the extra traffic has led to a rise in the number of people
buying the book I sell through Amazon and Lulu. I now sell a few a week,
compared to one every couple of months.
So, in answer to the title above, âYes.' I am getting what I wanted
â a wider audience for my writing.
Amount of referrals other sites receive
Below you can see the amount of referral visits my page generates to other
websites:
Referral traffic received from my competition page between January 2013 and
May 2013
One of the writing competitions I list was kind enough to share this data with
me. They were first listed on my site in January 2013.
A breakdown of figures can be seen below:
The highly relevant traffic I can offer writing websites makes being listed
appealing to most competitions. From speaking with the administrators of the
competition in the example above, I know that the traffic also converts well
into competition entries, so they are very happy with the results related to me
listing them.
This means that when I receive enquiries I can be confident in the value my
list offers.
Summary
So far, this experiment has proved that investing time in creating content
that is updated regularly can bring excellent results. In 2013, the page
attracts between 6,000 and 9,000 visits a month, 22% of which return to the page
time and again.
All you need to emulate this is some vision and common sense:
Find something your target audience wants
Give it to them
Keep the content fresh with regular updates and improvements
Listen to user suggestions and make changes accordingly
Listen to user suggestions about other resources they might find useful, and
create them
That's a content strategy that is likely to keep me busy for the next few
months and generate excellent results.
Keep it simple
One of the more common mistakes I've seen SEOs make is developing content no
one is interested in. You might end up creating something sexy based on an
amazing concept, but will it actually gain you the result you or your client
wants to see? Sometimes the more mundane ideas, like generating a useful list,
can work far more effectively. It might not be sexy, it might not look awesome,
but it is useful and can appeal to a community.
Keep it simple.
I believe you can learn more from those three words than you'd like to
believe. Looking forward to hearing your thoughts in the comments.
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten
hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think
of it as your exclusive digest of stuff you don't have time to hunt down but
want to read!
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/E6T0XiqCtVk/an-evergreen-content-case-study
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Thursday, 4 July 2013
Wednesday, 3 July 2013
[Build Great Backlinks] TITLE
Build Great Backlinks has posted a new item, 'Domain Migrations: Surviving the
Perfect Storm of Site Changes'
Posted by Ruth_Burr
Last week, I held a Mozinar talking about the SEO steps involved in
transitioning from SEOmoz.org to Moz.com, and sharing some of the results we
got. We got some great questions on the Mozinar, and I wanted a chance to answer
some more of them as well as expand on some points that didn't fit into the
Mozinar.
Throwing Best Practices to the Wind
As we spent more than a year planning the transition from SEOmoz to Moz, one
thing I wanted to make sure everyone knew internally was that we were engaging
in â well, maybe not worst practices, but we were pretty far away from
best practices when it came to domain migration.
One thing most SEOs will tell you about domain migration is that you
shouldnât make a lot of big changes at once. For example, if youâre
switching to a new domain, just switch domains; donât try to change
anything else at the same time. If youâre refreshing your design, just do
that; donât try to change your content or URL structure at the same time.
And definitely, definitely donât change anything else if youâre
changing your top-level domain (TLD).
Screenshot from "Achieving an SEO-Friendly Domain Migration - The Infographic"
by Aleyda Solis
Avoiding making this many changes to your website at once will mean that
search engines have a much easier time finding, crawling, and ranking your new
site, and that youâre much better positioned to diagnose problems as they
arise.
Nevertheless, there we were: plotting a massive re-brand, site redesign,
content overhaul, and domain change â complete with TLD switch â all
at the same time. A perfect storm. Itâs enough to make a person lose sleep
(I know I did). At the same time, Iâm glad we went through this, because
itâs exactly the kind of thing some of you are going to end up dealing
with as well. We needed to make all of these changes simultaneously in order to
do what we wanted to do with the new product and re-brand, and that took
precedence over SEO best practices. Instead of throwing up my hands and saying
âwell, weâre doomed,â I had to learn to do as much as I could
with the situation at hand.
Doing the Long, Boring, Hard Work
The major portion of my work preparing for the domain migration was my big
giant list of URLs:
Casey helped me pull a list of every URL on the site from our database, and I
found each URL a redirect target on Moz.com. I would recommend pulling your URL
list from your own database or server logs if itâs at all possible; it
will give you a much more complete list of URLs than simply running a crawl
using a program like Xenu or Screaming Frog.
When I talk to people about the migration, they typically blanch at the big
giant list of URLs. Is it really necessary to look at every URL on the site?
Well, no, not totally. In our case, there were large sections of the site
(like the blog and Q&A) that were staying largely the same â we could just
redirect everything at seomoz.org/blog/* to moz.com/blog/* without needing
further detail. For sites that are simply changing from one domain to another
without a major redesign/restructure (which, again, you should really do if you
can), it becomes even easier: If your siteâs staying exactly the same, you
can just redirect everything to the same folder location on your new domain.
Iâm so glad that I did go through every page on the site, though, since
I was able to get rid of a lot of old orphan pages, and help make sure the new
site taxonomy was more inclusive so we didnât have new orphan pages going
forward. A site migration is a great time to 301 old pages that have outlived
their usefulness to newer, more useful resources.
Traffic and Ranking Loss
I canât stress enough how important it is to manage expectations around
traffic and ranking loss during a domain migration. In the Mozinar, I mentioned
that some PageRank is lost through 301 redirects (thanks Ethan for sending along
this video from Matt Cutts explaining that the amount of PageRank that
dissipates through a 301 is currently identical to the amount that dissipates
through a link). This is usually not a huge deal for your most popular,
best-linked pages, but can be an issue for deep pages that rank for long-tail
terms, especially if the external links pointing to those pages are old or there
arenât very many of them.
With the Moz migration, the site restructure meant that we changed the
internal link juice flowing from page to page as well. In some cases that was
beneficial, such as with our Learn section which gained importance as it moved
from our footer to our (now-reduced) header. In other cases, however, it meant
some pages losing internal link equity. Again, not a huge issue for the most
important pages but definitely impactful on long-tail terms. Between those two
factors, the chance that our traffic and rankings wouldnât be affected was
pretty slim â and they were.
Better User Engagement
The flip side to the traffic loss was that we saw a boost in engagement
metrics. Cyrus ran a quick study on a subgroup of users who a) had arrived
through non-branded organic search and b) were new visitors to the site, to
mitigate as much as possible the influences of preconceived expectations and
industry âbuzzâ surrounding the re-brand. Hereâs what he
found:
As you can see, nearly every section on the site saw a boost in pageviews and
pages per visit, as well as a huge decrease in bounce rate. The only downside is
that we did see a decrease in time on page, pretty much across the board. We
have a few theories on that: It could be that the more people click around the
site, the less qualified each page view becomes; or it could be that the
redesign has, in many cases, made pages shorter and easier to read quickly. The
fact that time on page has decreased while average visit duration and bounce
rate have improved points to the lowered time on page not being an indicator of
lower quality, so thatâs good.
What About Changing Platforms?
I didnât get much of a chance to discuss changing CMS/Platforms in the
Mozinar, because we run the site on a custom back end and CMS. Itâs a
question we get a lot in Q&A, so I wanted to address it.
Like most domain migrations, itâs important to keep things as much
âthe sameâ as possible when migrating to a new platform or CMS.
Ideally, your site would look pretty much the same to users before and after the
change â you could start making improvements using your brand new shiny
CMS after the migration takes place. One thing thatâs especially important
to avoid when changing platforms or CMS is to make sure the new back end
isnât appending extra things to your URLs. For example, you want to make
sure your home page is still www.example.com and hasnât switched to
www.example.com/index or the like. Also be on the lookout for extensions such as
.html or .aspx being appended to your old URLs by the new platform. Thatâs
a really common cause of duplicate content on a new platform.
Sitemaps
In the Mozinar, I mentioned that we had multiple sitemaps in Google Webmaster
Tools, and got a question about why we do it that way. Since thatâs a
decision that was implemented before I came on, I wanted to make sure I had the
whole answer before I responded, but it was as I suspected. We have separate
sitemaps for our blog, Community profiles and YouMoz because those are three of
the largest areas of our site. Since each sitemap can only contain 50,000 URLs,
this multiple-map experience ensures we have plenty of room in each one for
these prolific sections to keep growing. Kate Morris wrote a great post on using
multiple sitemaps a couple years ago; you can read it here.
Noise in the Signal
âThis is great info, Ruth,â I can hear you saying, âbut why
did it take you a month to share it with us?â A lot of the reason has to
do with noise in the signal.
In the days surrounding the launch, we had increased buzz from our PR efforts
and excitement from our customers about the new site. We knew this would happen
â and were happy about it! â and that this uptick wasnât a
good indicator of how the new site would perform in the long term.
I also wanted to wait until SEOmoz pages were no longer ranking (as I
mentioned in the Mozinar, theyâre still indexed but arenât ranking
for any of our target terms) and had been replaced with Moz.com URLs, to get a
better sense of how our rankings were impacted before I shared the info. This
kind of longer-term analysis is important in the wake of a migration; make sure
youâre getting as accurate a picture as possible of your new metrics.
Thanks again to everyone who listened in on the Mozinar, and who sent your
kind wishes and congratulations to the Moz team during this process. It was a
huge effort by the whole company and weâre so happy to share it with you!
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten
hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think
of it as your exclusive digest of stuff you don't have time to hunt down but
want to read!
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/mZkjLyf7-n0/domain-migration-lessons
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Perfect Storm of Site Changes'
Posted by Ruth_Burr
Last week, I held a Mozinar talking about the SEO steps involved in
transitioning from SEOmoz.org to Moz.com, and sharing some of the results we
got. We got some great questions on the Mozinar, and I wanted a chance to answer
some more of them as well as expand on some points that didn't fit into the
Mozinar.
Throwing Best Practices to the Wind
As we spent more than a year planning the transition from SEOmoz to Moz, one
thing I wanted to make sure everyone knew internally was that we were engaging
in â well, maybe not worst practices, but we were pretty far away from
best practices when it came to domain migration.
One thing most SEOs will tell you about domain migration is that you
shouldnât make a lot of big changes at once. For example, if youâre
switching to a new domain, just switch domains; donât try to change
anything else at the same time. If youâre refreshing your design, just do
that; donât try to change your content or URL structure at the same time.
And definitely, definitely donât change anything else if youâre
changing your top-level domain (TLD).
Screenshot from "Achieving an SEO-Friendly Domain Migration - The Infographic"
by Aleyda Solis
Avoiding making this many changes to your website at once will mean that
search engines have a much easier time finding, crawling, and ranking your new
site, and that youâre much better positioned to diagnose problems as they
arise.
Nevertheless, there we were: plotting a massive re-brand, site redesign,
content overhaul, and domain change â complete with TLD switch â all
at the same time. A perfect storm. Itâs enough to make a person lose sleep
(I know I did). At the same time, Iâm glad we went through this, because
itâs exactly the kind of thing some of you are going to end up dealing
with as well. We needed to make all of these changes simultaneously in order to
do what we wanted to do with the new product and re-brand, and that took
precedence over SEO best practices. Instead of throwing up my hands and saying
âwell, weâre doomed,â I had to learn to do as much as I could
with the situation at hand.
Doing the Long, Boring, Hard Work
The major portion of my work preparing for the domain migration was my big
giant list of URLs:
Casey helped me pull a list of every URL on the site from our database, and I
found each URL a redirect target on Moz.com. I would recommend pulling your URL
list from your own database or server logs if itâs at all possible; it
will give you a much more complete list of URLs than simply running a crawl
using a program like Xenu or Screaming Frog.
When I talk to people about the migration, they typically blanch at the big
giant list of URLs. Is it really necessary to look at every URL on the site?
Well, no, not totally. In our case, there were large sections of the site
(like the blog and Q&A) that were staying largely the same â we could just
redirect everything at seomoz.org/blog/* to moz.com/blog/* without needing
further detail. For sites that are simply changing from one domain to another
without a major redesign/restructure (which, again, you should really do if you
can), it becomes even easier: If your siteâs staying exactly the same, you
can just redirect everything to the same folder location on your new domain.
Iâm so glad that I did go through every page on the site, though, since
I was able to get rid of a lot of old orphan pages, and help make sure the new
site taxonomy was more inclusive so we didnât have new orphan pages going
forward. A site migration is a great time to 301 old pages that have outlived
their usefulness to newer, more useful resources.
Traffic and Ranking Loss
I canât stress enough how important it is to manage expectations around
traffic and ranking loss during a domain migration. In the Mozinar, I mentioned
that some PageRank is lost through 301 redirects (thanks Ethan for sending along
this video from Matt Cutts explaining that the amount of PageRank that
dissipates through a 301 is currently identical to the amount that dissipates
through a link). This is usually not a huge deal for your most popular,
best-linked pages, but can be an issue for deep pages that rank for long-tail
terms, especially if the external links pointing to those pages are old or there
arenât very many of them.
With the Moz migration, the site restructure meant that we changed the
internal link juice flowing from page to page as well. In some cases that was
beneficial, such as with our Learn section which gained importance as it moved
from our footer to our (now-reduced) header. In other cases, however, it meant
some pages losing internal link equity. Again, not a huge issue for the most
important pages but definitely impactful on long-tail terms. Between those two
factors, the chance that our traffic and rankings wouldnât be affected was
pretty slim â and they were.
Better User Engagement
The flip side to the traffic loss was that we saw a boost in engagement
metrics. Cyrus ran a quick study on a subgroup of users who a) had arrived
through non-branded organic search and b) were new visitors to the site, to
mitigate as much as possible the influences of preconceived expectations and
industry âbuzzâ surrounding the re-brand. Hereâs what he
found:
As you can see, nearly every section on the site saw a boost in pageviews and
pages per visit, as well as a huge decrease in bounce rate. The only downside is
that we did see a decrease in time on page, pretty much across the board. We
have a few theories on that: It could be that the more people click around the
site, the less qualified each page view becomes; or it could be that the
redesign has, in many cases, made pages shorter and easier to read quickly. The
fact that time on page has decreased while average visit duration and bounce
rate have improved points to the lowered time on page not being an indicator of
lower quality, so thatâs good.
What About Changing Platforms?
I didnât get much of a chance to discuss changing CMS/Platforms in the
Mozinar, because we run the site on a custom back end and CMS. Itâs a
question we get a lot in Q&A, so I wanted to address it.
Like most domain migrations, itâs important to keep things as much
âthe sameâ as possible when migrating to a new platform or CMS.
Ideally, your site would look pretty much the same to users before and after the
change â you could start making improvements using your brand new shiny
CMS after the migration takes place. One thing thatâs especially important
to avoid when changing platforms or CMS is to make sure the new back end
isnât appending extra things to your URLs. For example, you want to make
sure your home page is still www.example.com and hasnât switched to
www.example.com/index or the like. Also be on the lookout for extensions such as
.html or .aspx being appended to your old URLs by the new platform. Thatâs
a really common cause of duplicate content on a new platform.
Sitemaps
In the Mozinar, I mentioned that we had multiple sitemaps in Google Webmaster
Tools, and got a question about why we do it that way. Since thatâs a
decision that was implemented before I came on, I wanted to make sure I had the
whole answer before I responded, but it was as I suspected. We have separate
sitemaps for our blog, Community profiles and YouMoz because those are three of
the largest areas of our site. Since each sitemap can only contain 50,000 URLs,
this multiple-map experience ensures we have plenty of room in each one for
these prolific sections to keep growing. Kate Morris wrote a great post on using
multiple sitemaps a couple years ago; you can read it here.
Noise in the Signal
âThis is great info, Ruth,â I can hear you saying, âbut why
did it take you a month to share it with us?â A lot of the reason has to
do with noise in the signal.
In the days surrounding the launch, we had increased buzz from our PR efforts
and excitement from our customers about the new site. We knew this would happen
â and were happy about it! â and that this uptick wasnât a
good indicator of how the new site would perform in the long term.
I also wanted to wait until SEOmoz pages were no longer ranking (as I
mentioned in the Mozinar, theyâre still indexed but arenât ranking
for any of our target terms) and had been replaced with Moz.com URLs, to get a
better sense of how our rankings were impacted before I shared the info. This
kind of longer-term analysis is important in the wake of a migration; make sure
youâre getting as accurate a picture as possible of your new metrics.
Thanks again to everyone who listened in on the Mozinar, and who sent your
kind wishes and congratulations to the Moz team during this process. It was a
huge effort by the whole company and weâre so happy to share it with you!
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten
hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think
of it as your exclusive digest of stuff you don't have time to hunt down but
want to read!
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/mZkjLyf7-n0/domain-migration-lessons
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Tuesday, 2 July 2013
[Build Great Backlinks] TITLE
Build Great Backlinks has posted a new item, 'The Right Keyword Data for the
Right Job'
Posted by russviranteThis post was originally in YouMoz, and was promoted to the
main blog because it provides great value and interest to our community. The
author's views are entirely his or her own and may not reflect the views of Moz,
Inc.
Ke...
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/viyM6y55ydc/the-right-keyword-data-for-the-right-job
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Right Job'
Posted by russviranteThis post was originally in YouMoz, and was promoted to the
main blog because it provides great value and interest to our community. The
author's views are entirely his or her own and may not reflect the views of Moz,
Inc.
Ke...
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/viyM6y55ydc/the-right-keyword-data-for-the-right-job
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
[Build Great Backlinks] TITLE
Build Great Backlinks has posted a new item, 'Why I Think ViperChill is Some
Sort of Scam'
Nothing to do with the fact that we share the same birthday, Louis Theroux is
without a doubt my favourite journalist / documentary producer. His shows cover
everything from brothels and the porn industry to profitable infomercial
companies and even cities ravaged by drugs. In a scene from one documentary,
Louis and the Nazis, hes [...]
You may view the latest post at
http://www.viperchill.com/viperchill-scam/
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Sort of Scam'
Nothing to do with the fact that we share the same birthday, Louis Theroux is
without a doubt my favourite journalist / documentary producer. His shows cover
everything from brothels and the porn industry to profitable infomercial
companies and even cities ravaged by drugs. In a scene from one documentary,
Louis and the Nazis, hes [...]
You may view the latest post at
http://www.viperchill.com/viperchill-scam/
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
[Build Great Backlinks] TITLE
Build Great Backlinks has posted a new item, 'The Definitive Guide to WordPress
Security'
Posted by SamAntics
This post was originally in YouMoz, and was promoted to the main blog because it
provides great value and interest to our community. The author's views are
entirely his or her own and may not reflect the views of Moz, Inc.
If you work in online marketing, the chances are good that you've worked on,
are working on, or will at some point work on a WordPress site. If you work with
wordpress.org in any capacity, this post is for you (much of this post doesn't
apply to *.wordpress.com hosted sites).
Script kiddies suck
In hacker lingo, a script kiddie is the lowliest form of hacker (using the
term hacker loosely), and relies on common tools and scripts to find and take
advantage of the weakest and most common security vulnerabilities: crappy
passwords, use of public WiFi without a VPN, outdated plugins, low-security
hosting, phishing attacks, and other things of this nature. Sadly, these issues
alone grant access to a shocking number of sites.
Unless you're in charge of a WordPress site for a major brand, the majority of
the security issues you're likely to face will be the result of script kiddies.
The good news is this: If you follow this guide, your site should be as close
to invulnerable as you can reasonably get. (To be fair, nothing is truly
invulnerable, but this will get you pretty close.) Abracadabra, vault-like
security is yours.
Without further ado, let's dive in. I personally take a four-tiered approach
to WordPress security:
Hosting and server level security
When it comes to securing WordPress, it's best to start from the ground up.
When you host your website with a hosting company that isn't sufficiently
security-conscious, if any site on a server is hacked, there's a chance that any
other site on that same server could be vulnerable.
After a ton of research, I've determined that the most secure option for
hosting Wordpress is WPEngine.com (and, conveniently, Moz has a PRO perk for
them, 4 months of free hosting).
The effort they put into security is re-freaking-diculous (seriously). I'm in
the process of moving all of my WordPress sites over to them as we speak. They
aren't cheap, but you get quite a lot for what you pay. They even have a
partnership with Sucuri Security, so if your site ever gets hacked, they'll fix
it for free.
That said, they might not be a perfect fit for everyone. For example, there
are quite a few plugins they don't allow (many for performance issues, not
security issues). There are alternates to most plugins though, so hopefully that
isn't a deal breaker.
If you HAVE to use another host for whatever reason, or need to host on your
own servers, there are a few things to keep in mind (WP Engine does most, if not
all, of this):
Run secure, stable versions of your web server and any software on that server.
Have a server-level firewall.
Keep your server under lock and key. Only your IT team should have access.
Never, ever access your server from an unsecure network.
If you need to FTP in, use SFTP via a reputable program (I like FileZilla).
Make sure your MySQL installation is as secure as possible.
Always create a unique database for each blog installation, and make sure your
database table DOES NOT begin with wp_.
Backup your database and other files as often as possible, especially right
before you make a change (there are plenty of options for this, such as
CodeGuard and VaultPress).
And, of course, make sure your passwords are both complex and not used
elsewhere.
There's more to this, but those are the biggies. If you want a lot more
detail, go here and here.
The next step in this process involves configuring some server rules. If you
have access to the main server configuration file, it's best to do these things
at that level, but not everyone is going to have that access. For that reason,
I'm going to cover how to do this via the .htaccess file by walking you through
a real .htaccess file (Note: edit your .htaccess file AFTER you install WP. It's
server-centric though, so I'm covering it here).
BIG FAT WARNING: Be very, very careful when making changes to your .htaccess
file. If you aren't extremely comfortable with code, it's best to let your
developer do this. I've personally used all of this code, exactly as is, but
I've seen bits work on some sites and break things on others (it totally depends
on your server configuration, plugins installed, etc.). To be safe, get your
developer to do this for you.
WordPress auto-creates a section in the .htaccess file. Don't put anything
inside of the WordPress section of the .htaccess, as it will be overwritten.
Some things will need to go before the WordPress .htaccess section, and some
things after, to avoid breaking things. If you don't know what should go where,
you probably shouldn't be editing your .htaccess file.
OK, here goes...
This first bit of code helps to prevent errors on some Apache servers, and
activates the rewrite engine (which many of these commands require to function):
## Include this at the start of your .htaccess file ##
Options +FollowSymlinks
RewriteEngine On
This next bit turns off the server signature. This is a "security by
obscurity" trick, as the less info a hacker has about your system, the harder it
is to get in. The more they know, the easier it is to go out and hunt for known
exploits:
## Disable the Server Signature ##
ServerSignature Off
Sometimes spammers will append their own crappy query strings to the end of a
URL, attempting to do all kinds of nasty things, and this next bit of code can
negate it by 301 redirecting certain query strings back to the canonical URL.
Just edit the enter|query|strings|here bit to include the query strings you're
having issues with, separated by pipes (a pipe is a separator in RegEx). This
next bit of code also has uses beyond blocking spammers, and can sort out issues
with ?replytocom and other common junk query strings:
## Remove Spammy Query Strings ##
<ifModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} enter|separated|query|strings|here [NC]
RewriteRule .* http://www.%{HTTP_HOST}/$1? [R=301,L]
</ifModule>
While not hacker-specific (though it certainly could be), this next bit of
code will prevent bots with no user agent from hitting your site. Just change
out yourwebsite.com with your actual URL before placing this in your .htaccess:
## Protect from spam bots ##
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.yourwebsite.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
</IfModule>
A common hacking tactic is a SQL injection, and this bit of code can block the
vast majority of attempts:
## SQL Injection Block ##
<IfModule mod_rewrite.c>
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|||"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^(.*)$ - [F,L]
</IfModule>
Now, there are plugins that can limit the number of login attempts from any
one IP address, but that doesn't prevent hackers from using large blocks of IPs
to brute-force your site (a la public proxy lists). I've experienced this first
hand numerous times, so the following bit of code has been a lifesaver as it
only allows my login pages to be reached from IP addresses I specify, and blocks
access to those pages from all other IPs.
Just adjust the allow from lines to reflect your actual IP addresses (you can
get your IP addresses by going to Google from each place you connect to the
internet and searching "What is my IP"). If needed, change the login filenames
as well (wp-login.php is default, and login is not, but my site uses both
because of a plugin I use).
Or, to make it easier on yourself, go to ProxyBonanza and pay $10/mo for one
exclusive proxy IP of your own, and then allow that IP and use that IP whenever
you want to access your sites. (ProxyBonanza has plugins for Firefox and Chrome,
which make this step really easy.) Just swap out the fake IPs below with your
actual IPs. If your IP changes, you can always go in and fix this via FTP later.
## Restrict WordPress Login Pages to Your Own IPs ##
<Files wp-login.php>
order deny,allow
deny from all
allow from 192.168.1.1
allow from 192.168.1.2
</Files>
<Files login>
order deny,allow
deny from all
allow from 192.168.1.1
allow from 192.168.1.1
</Files>
There are a number of files that nobody but you should ever be accessing, and
this bit of code will block them from being accessed via a browser:
## Block Sensitive Files ##
Options All -Indexes
<files .htaccess>
Order allow,deny
Deny from all
</files>
<files readme.html>
Order allow,deny
Deny from all
</files>
<files license.txt>
Order allow,deny
Deny from all
</files>
<files install.php>
Order allow,deny
Deny from all
</files>
<files wp-config.php>
Order allow,deny
Deny from all
</files>
<files error_log>
Order allow,deny
Deny from all
</files>
<files fantastico_fileslist.txt>
Order allow,deny
Deny from all
</files>
<files fantversion.php>
Order allow,deny
Deny from all
</files>
If you find your site being hit repeatedly with attack attempts from certain
IP addresses, you can manually block certain IPs with the following bit of code.
Just edit the deny from bit to include the offending IP, with one IP per line as
follows:
## Malicious IP Blocking ##
order allow,deny
deny from 1.1.1.1
deny from 2.2.2.2
allow from all
If you have people hitting you really often from the same IP or IP block, you
can redirect that IP/IP block to a nice rickroll video (just change the IP below
to reflect the one that's hitting you). :) I've done this on my sites for a few
repeat offenders:
## Redirect Recurring Spammer IPs to a Rickroll Video ##
RewriteCond %{REMOTE_ADDR} ^192\.168\.1\.1$
RewriteRule .* http://www.youtube.com/watch?v=oHg5SJYRHA0 [R=302,L]
If you have certain websites that are hitting you with referral traffic you
don't want (it can happen for various reasons), you can block those referring
domains with this code:
## Block Certain Referring Domains ##
RewriteCond %{HTTP_REFERER} digg\.com [NC]
RewriteRule .* â [F]
You can also use your .htaccess file to secure wp-includes (this can cause
real issues, especially with Multisite, so I'll have you go here for the
specifics). You can also do some other pretty advanced things, like blocking
certain countries and browser languages, if you so choose.
With all of that in place, your .htaccess file is just about as hardened as it
can get. An .htaccess file can exist for each directory on a site, and is
applied to everything in and under that directory. I've compiled this list from
a number of different articles, with a few bits of my own sprinkled in. For
further reading on these and other similar points, check out these five links.
The last step is to lock down your file permissions so that only those who
should have access to certain files have that access. You can read how to change
file permissions here (be careful with this one too, as it can break things,
particularly plugins.) This is something you should test very carefully as you
implement it, ideally in a sandbox or dev environment.
And that's it for WordPress server-level security (not really â you
could fill a book with this stuff â but this should be sufficient for your
needs). Next up, WordPress itself!
Your WordPress installation
Once you have your hosting and server security sorted out, it's time to get
WordPress installed, along with the necessary security plugins. Even if you
already have an existing WordPress site, don't skip this section!
You'll want to download the WordPress install files directly from
wordpress.org, and go through the install process via secure FTP (SFTP). Many
hosts offer a one-touch WP install, which is also fine. As you do this, make
sure you pick secure passwords (outlined in the next section), and don't use the
same password for more than one site/thing (separate passwords for your
database, FTP, WordPress admin, etc.)
With WordPress installed, the next step will be to pick a theme â and
not just any theme will do. As any black-hat SEO knows, themes and plugins have
long been a great way to get links, albeit in a shady and unethical way
(remember MozCon 2011, when Richard Baxter gave a live demonstration of pointing
millions of links with anchor text of his choice from a set of WordPress sites
running a theme/plugin he'd created? Yeah.)
Because a lot of potentially dangerous things can be hidden inside of themes,
it's a good idea to use or buy a secure, clean theme. The themes that come with
wordpress.org by default are pretty safe, but here are a few other options for
clean themes: Option 1 and Option 2. To get a better feel for why this is so
important, there's a great video here.
If you already have a theme installed, you might want to run a security scan,
or have a security-minded developer look through the theme code. Ditto for any
plugins you might have.
After you've selected your theme, the next step is to start picking plugins.
When it comes to plugins, you need to be just as careful as you were with
picking a theme. Even popular plugins can contain vulnerabilities, and
developers can sometimes be slow to fix them (or perhaps put them there
themselves). For that reason, I recommend using as few plugins as possible to
get the job done. That said, from a security perspective, here are the plugins I
highly recommend:
Better WP Security - This is sort of an all-in-one security option. It handles a
variety of tactics covered in this post. Can overlap with other plugins, so be
careful. Free.
Limit Login Attempts - Exactly what it says, and a phenomenal way to deter
brute-force hacking attempts on a site. Free.
Akismet - Great way to filter out a lot of crap before it ever touches your
site. If your site is easy to spam, it might also be easy to hack, so make it a
hardened target on all fronts. Paid.
Sucuri Security - When you pay for this service, you get a plugin to install on
your site that helps with the monitoring and hardening process. It has overlap
with other plugins though, such as Limit Login Attempts and Better WP Security,
so you don't want to use all of them at once. Paid.
CodeGuard - Great backup service that lets you easily roll back if you ever do
get hacked. Also, people don't back things up nearly as often as they should, so
doing it automatically is handy. Paid.
CloudFlare - CloudFlare is a CDN, but also so much more. It has some great
security features built in, and comes in both free and paid versions.
Google Authenticator - Enables two-factor authentication on WordPress, which is
awesome. I use two-factor wherever it's offered, because it rocks. Free.
Stealth Login Page - You can't crack what you can't find. This plugin hides your
login page without needing to edit .htaccess files. Free.
WordPress SEO by Yoast - Not only does this have great SEO benefits, but it
allows you to easily edit your .htaccess file from within the WordPress admin,
which is very handy. Free.
If you opt to use WP-Engine for your hosting, be aware that they are very
strict on what plugins they do and don't permit. I find this pretty annoying,
and while I understand their reasons, I really like some of the plugins they
don't permit.
If you have unused themes or plugins installed, I'd recommend deleting them.
Just having them installed on your site, even if they aren't active, can
potentially pose problems. You should also make sure that you keep WordPress,
your plugins and your themes up-to-date. Updates often fix known security
issues, and one of the first things a smart hacker looks for is out-of-date
plugins and themes they can exploit.
As you build out your site, you should also pay very close attention to what
is and isn't reachable by crawlers, and how your site handles things like login
info, passwords, lost passwords/password resets, security questions, etc.
There's an entire sub-set of hacking called Google hacking, dedicated to
surfacing information Google has found and indexed that it probably shouldn't
have (great article here). Making effective use of your robots.txt file to block
things that should be blocked is highly recommended.
While site security is never finished, this will sort out the vast majority of
problems you're likely to encounter. Remember, nothing is unhackable, so the
goal is simply to make your site more way trouble than it's worth to the
majority of hackers.
Personal security
As any half-decent hacker knows, the human element of security is usually the
weakest link in the chain. The most security-conscious web admin or host can be
foiled by a common password (Love, Sex, Secret, God, Hack the Planet!).
The human brain likes routines, patterns, and comfort zones; and hackers
exploit that with glee! If you want a fascinating yet frightening read on this
topic, check out Kevin Mitnick's book The Art of Deception.
Here are my seven personal best practices for locking down the human element:
Never access a WiFi hotspot through anything other than a secure VPN. I
personally use Cloak as my VPN (iOS and Mac only at this point), but there are
lots of options. You'd be shocked at what can be found with simple packet
sniffing (Firesheep is a great example, and will probably make you quite
uncomfortable). When you use a WiFi network, secured or unsecured, anyone else
on that network can get access to your traffic (if all your traffic is
encrypted, you're MUCH safer, which is why you should use a secure VPN on any
shared network, even if it's a "secure" shared network). If you have WiFi at
home or work, make the password a strong one, use WPA2, and set your router to
NOT display the SSID (this is a "security by obscurity" tactic).
Get a firewall. A good firewall is an excellent defensive tool. In a perfect
world, I'd recommend having both a software and a hardware firewall, but that
may not be feasible for everyone. At the very least, you need a software
firewall (Comodo, ZoneAlarm, etc.). It can be a bit intrusive, depending on your
settings, but it's easy to customize and does a very good job. You should have a
firewall on every desktop/laptop/server.
See, there you go, a good firewall. Not much is getting past that...
Get an antivirus program. Viruses and malware are a dime a dozen, and the
chances are REALLY good that you've got at least one on your machine already. If
a hacker has access to your computer, no amount of security anywhere else can
protect your WordPress installation (not to mention your email, bank account,
etc.) I've tried quite a few over the years, and I'm partial to Avast. It's one
of the least resource-intensive AV programs on the market (won't bog down your
machine), but it's also extremely thorough (there's a free version, but I pay
for the full suite for a variety of reasons).
Keep your hardware physically secure. If someone can get to your machine, it's a
cinch to hook up a keylogger. If you don't password protect your machine, there
are all kinds of other quick and dirty things they could do as well. If you use
a desktop in particular, and it's in a common area at work, periodically check
your USB ports and all cords running into the machine for anything unusual. It's
uncommon, but it happens. Seriously, you should see the type of security Google
has at its server farms!
Use really good passwords, and don't ever reuse passwords on multiple sites.
Here's where the lazy human element really comes into play. We're not really
good at remembering obscure passwords, so we tend to stick with things we'll
remember (asdf, 12345678, qwerty12345, etc.). This is bad, because common
passwords make things REALLY easy for hackers, especially if you use the same
password for multiple sites (don't do that, ever).
Operating system passwords are notoriously easy to crack with rainbow tables,
so make sure your OS password is long (at least 15 characters) and complex
(uppercase and lowercase letters, numbers and symbols, avoiding common
substitutions like @ for A or 8 for B, etc.). Here's a cool article that
explains why complex passwords make things SO much harder for hackers.
Thanks to some pretty serious security blunders over the years, it's easy to
find massive lists of passwords used on pretty major sites (RockYou is a great
example, with 32 million passwords leaked). With a list like that, you can just
pick a WordPress site and try random passwords at will until you get a hit.
While far from efficient, script kiddies in particular love this brute-force
approach.
I've found the easiest way to have virtually unbreakable passwords is to use
a tool like LastPass, 1Password or Roboform. They allow you to generate a
random, long, extremely complex password for each site, and then encrypt and
store them all with one master password. There are desktop and mobile apps
available (some of which even contain a secure browsing environment), so you can
easily login from your various devices, and all you have to remember is one
password to access them all (for the love of all that is holy, at least make
that one password complex).
Don't write down, print, or store your passwords in plain text on your
computer. Just don't.
Protect your email accounts with two-factor authentication (and then protect
your phone too). If a hacker can't get into your site via the password, their
next trick is usually trying to crack your email account so they can just do a
reset. If your email provider offers two-factor authentication, USE IT.
If you do this, make sure you lock your phone (use a real password, not the 4
digit variety) and try really hard not to lose it, since that is now the key to
your accounts (and, in a perfect world, don't put that phone number up online,
just to be safe. If a website ever needs a phone number, get a Google Voice
number that you use just for that.) You should probably also set your phone to
wipe after a certain number of failed tries, and configure a remote wipe option
as well, if possible, as your phone is now the key to your accounts.
If your account provider asks you for security questions, use a mnemonic to
come up with a totally separate answer (for example: for the question "What was
your high school mascot?", I might think, I really hated my CS teacher in high
school, and then use that teacher's name as the answer.) This will effectively
neutralize attempts to mine your social profiles for data hackers can use to
guess your security questions.
Learn to recognize and avoid phishing attacks. Whether by email or website,
phishing attacks are one of the most common causes of security breaches (you
might have heard about the hacked AP Twitter account fiasco that caused a
massive stock drop â yeah, that was due to a phishing attack).
When it comes to avoiding these sorts of attacks, I live by three rules:
If I have to log in to a site, I only navigate to that site through my
password manager (this prevents me from accidentally falling for a misspelling
URL phishing attack, like if I were to type Facebool.com instead of
Facebook.com).
Never, ever click on a link in an email and then login to whatever page pops
up (see last rule). In fact, I don't click on links in email anymore. I
right-click, copy link location, and then paste it into Google, just to be safe.
If it doesn't look right, or the results include spammy stuff, I stop there.
Never, ever open an attachment from someone you don't know and trust (and even
if you know and trust them, drop it in a folder and run a virus check on it
before opening it, or open it in a sandbox program first just to be safe). If
someone who has you in their contact list gets their email hacked, the hackers
start by blasting out emails to that person's contact list to expand their
phishing pond.
Last but not least, exercise constant diligence
When it comes to WordPress security, you can't just set it and forget it.
If you put all of this in place, and then fail to monitor and update and
change things as time goes by, you'll be in just as bad of shape as if you'd
never done any of this to begin with.
To make sure that all of your hard work doesn't go to waste, I recommend a
seven-step checklist to maintain constant vigilance for your WordPress sites:
Keep WordPress updated. I'm in my sites daily, so I keep an eye on this daily.
WordPress doesn't update the core too terribly often, so I'd recommend checking
this at least monthly to be safe. You might want to have your dev team do this,
as updates sometimes break things.
Keep your plugins updated. Plugins are one of the most vulnerable parts of
WordPress, not only to external hackers, but to malicious or greedy programmers.
While we already covered only using reputable plugins, also make sure you keep
these plugins updated, just in case a vulnerability is being addressed in the
update. Again, you might want to have your dev team do this, as updates can
sometimes break things.
Monitor your server log files. This might be overkill for most folks, unless
you've spotted something suspicious. Your server logs will give you the details
of everything that has hit your site, human or bot, and when and from what IP
address. You can find some awesome stuff in here, so keep an eye on it from time
to time. (AWStats is a good free tool for this.)
Monitor WP access. You can use a plugin like Simple Login Log to monitor the
details of logins to your site. DO THIS.
Monitor for file changes. A plugin like CodeGuard will send you emails whenever
your WordPress files are changed. This can be an early-warning system for a
hack, and is worth the investment. It also allows you to roll back changes if
needed.
Change your password periodically. I'd recommend every 3-6 months, but once per
year is probably sufficient if you're using a sufficiently complex and unique
password.
Keep Your Firewall and Antivirus Software Updated - New threats are discovered
constantly, so it's important to keep everything updated. Out-of-date security
software is a vulnerability.
There are literally books worth of information on this (you've kind of just
read one), so I'll leave it at that. If you follow these guidelines, and make
the recommended changes, your WordPress site (and all your other accounts for
that matter) will be as secure as reasonably possible.Sign up for The Moz Top
10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news,
tips, and rad links uncovered by the Moz team. Think of it as your exclusive
digest of stuff you don't have time to hunt down but want to read!
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/A8LHs7lVRjo/the-definitive-guide-to-wordpress-security
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Security'
Posted by SamAntics
This post was originally in YouMoz, and was promoted to the main blog because it
provides great value and interest to our community. The author's views are
entirely his or her own and may not reflect the views of Moz, Inc.
If you work in online marketing, the chances are good that you've worked on,
are working on, or will at some point work on a WordPress site. If you work with
wordpress.org in any capacity, this post is for you (much of this post doesn't
apply to *.wordpress.com hosted sites).
Script kiddies suck
In hacker lingo, a script kiddie is the lowliest form of hacker (using the
term hacker loosely), and relies on common tools and scripts to find and take
advantage of the weakest and most common security vulnerabilities: crappy
passwords, use of public WiFi without a VPN, outdated plugins, low-security
hosting, phishing attacks, and other things of this nature. Sadly, these issues
alone grant access to a shocking number of sites.
Unless you're in charge of a WordPress site for a major brand, the majority of
the security issues you're likely to face will be the result of script kiddies.
The good news is this: If you follow this guide, your site should be as close
to invulnerable as you can reasonably get. (To be fair, nothing is truly
invulnerable, but this will get you pretty close.) Abracadabra, vault-like
security is yours.
Without further ado, let's dive in. I personally take a four-tiered approach
to WordPress security:
Hosting and server level security
When it comes to securing WordPress, it's best to start from the ground up.
When you host your website with a hosting company that isn't sufficiently
security-conscious, if any site on a server is hacked, there's a chance that any
other site on that same server could be vulnerable.
After a ton of research, I've determined that the most secure option for
hosting Wordpress is WPEngine.com (and, conveniently, Moz has a PRO perk for
them, 4 months of free hosting).
The effort they put into security is re-freaking-diculous (seriously). I'm in
the process of moving all of my WordPress sites over to them as we speak. They
aren't cheap, but you get quite a lot for what you pay. They even have a
partnership with Sucuri Security, so if your site ever gets hacked, they'll fix
it for free.
That said, they might not be a perfect fit for everyone. For example, there
are quite a few plugins they don't allow (many for performance issues, not
security issues). There are alternates to most plugins though, so hopefully that
isn't a deal breaker.
If you HAVE to use another host for whatever reason, or need to host on your
own servers, there are a few things to keep in mind (WP Engine does most, if not
all, of this):
Run secure, stable versions of your web server and any software on that server.
Have a server-level firewall.
Keep your server under lock and key. Only your IT team should have access.
Never, ever access your server from an unsecure network.
If you need to FTP in, use SFTP via a reputable program (I like FileZilla).
Make sure your MySQL installation is as secure as possible.
Always create a unique database for each blog installation, and make sure your
database table DOES NOT begin with wp_.
Backup your database and other files as often as possible, especially right
before you make a change (there are plenty of options for this, such as
CodeGuard and VaultPress).
And, of course, make sure your passwords are both complex and not used
elsewhere.
There's more to this, but those are the biggies. If you want a lot more
detail, go here and here.
The next step in this process involves configuring some server rules. If you
have access to the main server configuration file, it's best to do these things
at that level, but not everyone is going to have that access. For that reason,
I'm going to cover how to do this via the .htaccess file by walking you through
a real .htaccess file (Note: edit your .htaccess file AFTER you install WP. It's
server-centric though, so I'm covering it here).
BIG FAT WARNING: Be very, very careful when making changes to your .htaccess
file. If you aren't extremely comfortable with code, it's best to let your
developer do this. I've personally used all of this code, exactly as is, but
I've seen bits work on some sites and break things on others (it totally depends
on your server configuration, plugins installed, etc.). To be safe, get your
developer to do this for you.
WordPress auto-creates a section in the .htaccess file. Don't put anything
inside of the WordPress section of the .htaccess, as it will be overwritten.
Some things will need to go before the WordPress .htaccess section, and some
things after, to avoid breaking things. If you don't know what should go where,
you probably shouldn't be editing your .htaccess file.
OK, here goes...
This first bit of code helps to prevent errors on some Apache servers, and
activates the rewrite engine (which many of these commands require to function):
## Include this at the start of your .htaccess file ##
Options +FollowSymlinks
RewriteEngine On
This next bit turns off the server signature. This is a "security by
obscurity" trick, as the less info a hacker has about your system, the harder it
is to get in. The more they know, the easier it is to go out and hunt for known
exploits:
## Disable the Server Signature ##
ServerSignature Off
Sometimes spammers will append their own crappy query strings to the end of a
URL, attempting to do all kinds of nasty things, and this next bit of code can
negate it by 301 redirecting certain query strings back to the canonical URL.
Just edit the enter|query|strings|here bit to include the query strings you're
having issues with, separated by pipes (a pipe is a separator in RegEx). This
next bit of code also has uses beyond blocking spammers, and can sort out issues
with ?replytocom and other common junk query strings:
## Remove Spammy Query Strings ##
<ifModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} enter|separated|query|strings|here [NC]
RewriteRule .* http://www.%{HTTP_HOST}/$1? [R=301,L]
</ifModule>
While not hacker-specific (though it certainly could be), this next bit of
code will prevent bots with no user agent from hitting your site. Just change
out yourwebsite.com with your actual URL before placing this in your .htaccess:
## Protect from spam bots ##
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.yourwebsite.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
</IfModule>
A common hacking tactic is a SQL injection, and this bit of code can block the
vast majority of attempts:
## SQL Injection Block ##
<IfModule mod_rewrite.c>
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|||"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^(.*)$ - [F,L]
</IfModule>
Now, there are plugins that can limit the number of login attempts from any
one IP address, but that doesn't prevent hackers from using large blocks of IPs
to brute-force your site (a la public proxy lists). I've experienced this first
hand numerous times, so the following bit of code has been a lifesaver as it
only allows my login pages to be reached from IP addresses I specify, and blocks
access to those pages from all other IPs.
Just adjust the allow from lines to reflect your actual IP addresses (you can
get your IP addresses by going to Google from each place you connect to the
internet and searching "What is my IP"). If needed, change the login filenames
as well (wp-login.php is default, and login is not, but my site uses both
because of a plugin I use).
Or, to make it easier on yourself, go to ProxyBonanza and pay $10/mo for one
exclusive proxy IP of your own, and then allow that IP and use that IP whenever
you want to access your sites. (ProxyBonanza has plugins for Firefox and Chrome,
which make this step really easy.) Just swap out the fake IPs below with your
actual IPs. If your IP changes, you can always go in and fix this via FTP later.
## Restrict WordPress Login Pages to Your Own IPs ##
<Files wp-login.php>
order deny,allow
deny from all
allow from 192.168.1.1
allow from 192.168.1.2
</Files>
<Files login>
order deny,allow
deny from all
allow from 192.168.1.1
allow from 192.168.1.1
</Files>
There are a number of files that nobody but you should ever be accessing, and
this bit of code will block them from being accessed via a browser:
## Block Sensitive Files ##
Options All -Indexes
<files .htaccess>
Order allow,deny
Deny from all
</files>
<files readme.html>
Order allow,deny
Deny from all
</files>
<files license.txt>
Order allow,deny
Deny from all
</files>
<files install.php>
Order allow,deny
Deny from all
</files>
<files wp-config.php>
Order allow,deny
Deny from all
</files>
<files error_log>
Order allow,deny
Deny from all
</files>
<files fantastico_fileslist.txt>
Order allow,deny
Deny from all
</files>
<files fantversion.php>
Order allow,deny
Deny from all
</files>
If you find your site being hit repeatedly with attack attempts from certain
IP addresses, you can manually block certain IPs with the following bit of code.
Just edit the deny from bit to include the offending IP, with one IP per line as
follows:
## Malicious IP Blocking ##
order allow,deny
deny from 1.1.1.1
deny from 2.2.2.2
allow from all
If you have people hitting you really often from the same IP or IP block, you
can redirect that IP/IP block to a nice rickroll video (just change the IP below
to reflect the one that's hitting you). :) I've done this on my sites for a few
repeat offenders:
## Redirect Recurring Spammer IPs to a Rickroll Video ##
RewriteCond %{REMOTE_ADDR} ^192\.168\.1\.1$
RewriteRule .* http://www.youtube.com/watch?v=oHg5SJYRHA0 [R=302,L]
If you have certain websites that are hitting you with referral traffic you
don't want (it can happen for various reasons), you can block those referring
domains with this code:
## Block Certain Referring Domains ##
RewriteCond %{HTTP_REFERER} digg\.com [NC]
RewriteRule .* â [F]
You can also use your .htaccess file to secure wp-includes (this can cause
real issues, especially with Multisite, so I'll have you go here for the
specifics). You can also do some other pretty advanced things, like blocking
certain countries and browser languages, if you so choose.
With all of that in place, your .htaccess file is just about as hardened as it
can get. An .htaccess file can exist for each directory on a site, and is
applied to everything in and under that directory. I've compiled this list from
a number of different articles, with a few bits of my own sprinkled in. For
further reading on these and other similar points, check out these five links.
The last step is to lock down your file permissions so that only those who
should have access to certain files have that access. You can read how to change
file permissions here (be careful with this one too, as it can break things,
particularly plugins.) This is something you should test very carefully as you
implement it, ideally in a sandbox or dev environment.
And that's it for WordPress server-level security (not really â you
could fill a book with this stuff â but this should be sufficient for your
needs). Next up, WordPress itself!
Your WordPress installation
Once you have your hosting and server security sorted out, it's time to get
WordPress installed, along with the necessary security plugins. Even if you
already have an existing WordPress site, don't skip this section!
You'll want to download the WordPress install files directly from
wordpress.org, and go through the install process via secure FTP (SFTP). Many
hosts offer a one-touch WP install, which is also fine. As you do this, make
sure you pick secure passwords (outlined in the next section), and don't use the
same password for more than one site/thing (separate passwords for your
database, FTP, WordPress admin, etc.)
With WordPress installed, the next step will be to pick a theme â and
not just any theme will do. As any black-hat SEO knows, themes and plugins have
long been a great way to get links, albeit in a shady and unethical way
(remember MozCon 2011, when Richard Baxter gave a live demonstration of pointing
millions of links with anchor text of his choice from a set of WordPress sites
running a theme/plugin he'd created? Yeah.)
Because a lot of potentially dangerous things can be hidden inside of themes,
it's a good idea to use or buy a secure, clean theme. The themes that come with
wordpress.org by default are pretty safe, but here are a few other options for
clean themes: Option 1 and Option 2. To get a better feel for why this is so
important, there's a great video here.
If you already have a theme installed, you might want to run a security scan,
or have a security-minded developer look through the theme code. Ditto for any
plugins you might have.
After you've selected your theme, the next step is to start picking plugins.
When it comes to plugins, you need to be just as careful as you were with
picking a theme. Even popular plugins can contain vulnerabilities, and
developers can sometimes be slow to fix them (or perhaps put them there
themselves). For that reason, I recommend using as few plugins as possible to
get the job done. That said, from a security perspective, here are the plugins I
highly recommend:
Better WP Security - This is sort of an all-in-one security option. It handles a
variety of tactics covered in this post. Can overlap with other plugins, so be
careful. Free.
Limit Login Attempts - Exactly what it says, and a phenomenal way to deter
brute-force hacking attempts on a site. Free.
Akismet - Great way to filter out a lot of crap before it ever touches your
site. If your site is easy to spam, it might also be easy to hack, so make it a
hardened target on all fronts. Paid.
Sucuri Security - When you pay for this service, you get a plugin to install on
your site that helps with the monitoring and hardening process. It has overlap
with other plugins though, such as Limit Login Attempts and Better WP Security,
so you don't want to use all of them at once. Paid.
CodeGuard - Great backup service that lets you easily roll back if you ever do
get hacked. Also, people don't back things up nearly as often as they should, so
doing it automatically is handy. Paid.
CloudFlare - CloudFlare is a CDN, but also so much more. It has some great
security features built in, and comes in both free and paid versions.
Google Authenticator - Enables two-factor authentication on WordPress, which is
awesome. I use two-factor wherever it's offered, because it rocks. Free.
Stealth Login Page - You can't crack what you can't find. This plugin hides your
login page without needing to edit .htaccess files. Free.
WordPress SEO by Yoast - Not only does this have great SEO benefits, but it
allows you to easily edit your .htaccess file from within the WordPress admin,
which is very handy. Free.
If you opt to use WP-Engine for your hosting, be aware that they are very
strict on what plugins they do and don't permit. I find this pretty annoying,
and while I understand their reasons, I really like some of the plugins they
don't permit.
If you have unused themes or plugins installed, I'd recommend deleting them.
Just having them installed on your site, even if they aren't active, can
potentially pose problems. You should also make sure that you keep WordPress,
your plugins and your themes up-to-date. Updates often fix known security
issues, and one of the first things a smart hacker looks for is out-of-date
plugins and themes they can exploit.
As you build out your site, you should also pay very close attention to what
is and isn't reachable by crawlers, and how your site handles things like login
info, passwords, lost passwords/password resets, security questions, etc.
There's an entire sub-set of hacking called Google hacking, dedicated to
surfacing information Google has found and indexed that it probably shouldn't
have (great article here). Making effective use of your robots.txt file to block
things that should be blocked is highly recommended.
While site security is never finished, this will sort out the vast majority of
problems you're likely to encounter. Remember, nothing is unhackable, so the
goal is simply to make your site more way trouble than it's worth to the
majority of hackers.
Personal security
As any half-decent hacker knows, the human element of security is usually the
weakest link in the chain. The most security-conscious web admin or host can be
foiled by a common password (Love, Sex, Secret, God, Hack the Planet!).
The human brain likes routines, patterns, and comfort zones; and hackers
exploit that with glee! If you want a fascinating yet frightening read on this
topic, check out Kevin Mitnick's book The Art of Deception.
Here are my seven personal best practices for locking down the human element:
Never access a WiFi hotspot through anything other than a secure VPN. I
personally use Cloak as my VPN (iOS and Mac only at this point), but there are
lots of options. You'd be shocked at what can be found with simple packet
sniffing (Firesheep is a great example, and will probably make you quite
uncomfortable). When you use a WiFi network, secured or unsecured, anyone else
on that network can get access to your traffic (if all your traffic is
encrypted, you're MUCH safer, which is why you should use a secure VPN on any
shared network, even if it's a "secure" shared network). If you have WiFi at
home or work, make the password a strong one, use WPA2, and set your router to
NOT display the SSID (this is a "security by obscurity" tactic).
Get a firewall. A good firewall is an excellent defensive tool. In a perfect
world, I'd recommend having both a software and a hardware firewall, but that
may not be feasible for everyone. At the very least, you need a software
firewall (Comodo, ZoneAlarm, etc.). It can be a bit intrusive, depending on your
settings, but it's easy to customize and does a very good job. You should have a
firewall on every desktop/laptop/server.
See, there you go, a good firewall. Not much is getting past that...
Get an antivirus program. Viruses and malware are a dime a dozen, and the
chances are REALLY good that you've got at least one on your machine already. If
a hacker has access to your computer, no amount of security anywhere else can
protect your WordPress installation (not to mention your email, bank account,
etc.) I've tried quite a few over the years, and I'm partial to Avast. It's one
of the least resource-intensive AV programs on the market (won't bog down your
machine), but it's also extremely thorough (there's a free version, but I pay
for the full suite for a variety of reasons).
Keep your hardware physically secure. If someone can get to your machine, it's a
cinch to hook up a keylogger. If you don't password protect your machine, there
are all kinds of other quick and dirty things they could do as well. If you use
a desktop in particular, and it's in a common area at work, periodically check
your USB ports and all cords running into the machine for anything unusual. It's
uncommon, but it happens. Seriously, you should see the type of security Google
has at its server farms!
Use really good passwords, and don't ever reuse passwords on multiple sites.
Here's where the lazy human element really comes into play. We're not really
good at remembering obscure passwords, so we tend to stick with things we'll
remember (asdf, 12345678, qwerty12345, etc.). This is bad, because common
passwords make things REALLY easy for hackers, especially if you use the same
password for multiple sites (don't do that, ever).
Operating system passwords are notoriously easy to crack with rainbow tables,
so make sure your OS password is long (at least 15 characters) and complex
(uppercase and lowercase letters, numbers and symbols, avoiding common
substitutions like @ for A or 8 for B, etc.). Here's a cool article that
explains why complex passwords make things SO much harder for hackers.
Thanks to some pretty serious security blunders over the years, it's easy to
find massive lists of passwords used on pretty major sites (RockYou is a great
example, with 32 million passwords leaked). With a list like that, you can just
pick a WordPress site and try random passwords at will until you get a hit.
While far from efficient, script kiddies in particular love this brute-force
approach.
I've found the easiest way to have virtually unbreakable passwords is to use
a tool like LastPass, 1Password or Roboform. They allow you to generate a
random, long, extremely complex password for each site, and then encrypt and
store them all with one master password. There are desktop and mobile apps
available (some of which even contain a secure browsing environment), so you can
easily login from your various devices, and all you have to remember is one
password to access them all (for the love of all that is holy, at least make
that one password complex).
Don't write down, print, or store your passwords in plain text on your
computer. Just don't.
Protect your email accounts with two-factor authentication (and then protect
your phone too). If a hacker can't get into your site via the password, their
next trick is usually trying to crack your email account so they can just do a
reset. If your email provider offers two-factor authentication, USE IT.
If you do this, make sure you lock your phone (use a real password, not the 4
digit variety) and try really hard not to lose it, since that is now the key to
your accounts (and, in a perfect world, don't put that phone number up online,
just to be safe. If a website ever needs a phone number, get a Google Voice
number that you use just for that.) You should probably also set your phone to
wipe after a certain number of failed tries, and configure a remote wipe option
as well, if possible, as your phone is now the key to your accounts.
If your account provider asks you for security questions, use a mnemonic to
come up with a totally separate answer (for example: for the question "What was
your high school mascot?", I might think, I really hated my CS teacher in high
school, and then use that teacher's name as the answer.) This will effectively
neutralize attempts to mine your social profiles for data hackers can use to
guess your security questions.
Learn to recognize and avoid phishing attacks. Whether by email or website,
phishing attacks are one of the most common causes of security breaches (you
might have heard about the hacked AP Twitter account fiasco that caused a
massive stock drop â yeah, that was due to a phishing attack).
When it comes to avoiding these sorts of attacks, I live by three rules:
If I have to log in to a site, I only navigate to that site through my
password manager (this prevents me from accidentally falling for a misspelling
URL phishing attack, like if I were to type Facebool.com instead of
Facebook.com).
Never, ever click on a link in an email and then login to whatever page pops
up (see last rule). In fact, I don't click on links in email anymore. I
right-click, copy link location, and then paste it into Google, just to be safe.
If it doesn't look right, or the results include spammy stuff, I stop there.
Never, ever open an attachment from someone you don't know and trust (and even
if you know and trust them, drop it in a folder and run a virus check on it
before opening it, or open it in a sandbox program first just to be safe). If
someone who has you in their contact list gets their email hacked, the hackers
start by blasting out emails to that person's contact list to expand their
phishing pond.
Last but not least, exercise constant diligence
When it comes to WordPress security, you can't just set it and forget it.
If you put all of this in place, and then fail to monitor and update and
change things as time goes by, you'll be in just as bad of shape as if you'd
never done any of this to begin with.
To make sure that all of your hard work doesn't go to waste, I recommend a
seven-step checklist to maintain constant vigilance for your WordPress sites:
Keep WordPress updated. I'm in my sites daily, so I keep an eye on this daily.
WordPress doesn't update the core too terribly often, so I'd recommend checking
this at least monthly to be safe. You might want to have your dev team do this,
as updates sometimes break things.
Keep your plugins updated. Plugins are one of the most vulnerable parts of
WordPress, not only to external hackers, but to malicious or greedy programmers.
While we already covered only using reputable plugins, also make sure you keep
these plugins updated, just in case a vulnerability is being addressed in the
update. Again, you might want to have your dev team do this, as updates can
sometimes break things.
Monitor your server log files. This might be overkill for most folks, unless
you've spotted something suspicious. Your server logs will give you the details
of everything that has hit your site, human or bot, and when and from what IP
address. You can find some awesome stuff in here, so keep an eye on it from time
to time. (AWStats is a good free tool for this.)
Monitor WP access. You can use a plugin like Simple Login Log to monitor the
details of logins to your site. DO THIS.
Monitor for file changes. A plugin like CodeGuard will send you emails whenever
your WordPress files are changed. This can be an early-warning system for a
hack, and is worth the investment. It also allows you to roll back changes if
needed.
Change your password periodically. I'd recommend every 3-6 months, but once per
year is probably sufficient if you're using a sufficiently complex and unique
password.
Keep Your Firewall and Antivirus Software Updated - New threats are discovered
constantly, so it's important to keep everything updated. Out-of-date security
software is a vulnerability.
There are literally books worth of information on this (you've kind of just
read one), so I'll leave it at that. If you follow these guidelines, and make
the recommended changes, your WordPress site (and all your other accounts for
that matter) will be as secure as reasonably possible.Sign up for The Moz Top
10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news,
tips, and rad links uncovered by the Moz team. Think of it as your exclusive
digest of stuff you don't have time to hunt down but want to read!
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/A8LHs7lVRjo/the-definitive-guide-to-wordpress-security
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Monday, 1 July 2013
[Build Great Backlinks] TITLE
Build Great Backlinks has posted a new item, '#MozCon Speaker Interviews:
Avinash & Annie'
Posted by Lindsay
Today I'm excited to bring you a short interview with two of the top web
analytics professionals in the industry, Avinash Kaushik and Annie Cushing. Not
only are they experts at leveraging data effectively, theyâre incredible
conference speakers who are returning to MozCon this year!
Avinash Kaushik is the digital marketing evangelist at Google and co-founder of
Market Motive. He is also the author of two best-selling books, Web Analytics
2.0 and Web Analytics: An Hour A Day, and he writes a popular web analytics
blog, Occam's Razor.
Heâs an energetic speaker who delivers eye-opening insights about the
power of data that you can put into action immediately. He gave an awesome
presentation at MozCon 2011 which inspired a flood of tweets and ended with a
standing ovation.
Annie Cushing is an SEO and analytics consultant. Her areas of expertise are
analytics, technical SEO, and everything to do with data â collection,
analysis, and beautification. Sheâs on a mission to rid the world of ugly
data, one spreadsheet at a time.
If you donât think analytics can be sexy, chances are Annie will change
your mind. She shares practical, actionable information that revolves around one
of her passions â making data sexy. At MozCon 2012, the audience at her
amazing presentation left with tons of useful tips and tricks for creating Excel
spreadsheets that are comprehensive, easy to understand, and compelling to
decision-makers.
We are honored that Avinash and Annie are joining us again at MozCon, and we
hope you will join us, too! Their talks will help you demystify analytics data
the moment you get back to the office.
In his keynote, âSimplifying Complexity: Three Ideas For Higher
ROI,â Avinash will apply Occamâs Razor to three user cases and share
practical tips for dealing with complexity. Annie will show you how to separate
the junk from the sound data when analyzing organic keyword data in her talk,
âBreaking Up With Your Keyword-Based KPIs.â
Recently, Avinash and Annie were kind enough to answer a few questions about
their upcoming MozCon presentations, must-know analytics information, and which
technology would improve their lives.
Tell us about the presentation you have planned for MozCon.
Avinash: My plan is to share three stories that serve as an example of
amplifying the awesomeness of any business not by focusing on doing one thing
well. That seems like such an odd thing to say, but I've convinced that if we
are to make incredible progress we need to solve for multiplicity.
Three simple examples, from our everyday lives, that the audience will be able
to go back and implement in their day to day efforts.
Annie: Iâm going to talk about breaking up with your organic keyword
data. Many marketers (if not most) who focus on organic search are using junk
data that does not stand up to scientific criteria. Iâm going to talk
about what data is junk, how to differentiate junk from sound data, and some
alternatives to junk data that withstand statistical scrutiny.
What is something that all marketers should know about web analytics, but
many donât seem to know?
Avinash: My 10/90 rule. For every $100 you need to invest in making smarter
decisions on the web, you need to invest $10 in tools and consultants to
implement the tools, and you need to invest $90 in big brains to analyze the
data and recommend actions.
People have this insane belief that data talks. No. Data does not talk; people
make data talk.
The question to ask, hence, is not how much data you have. The question is how
many big brains you have.
Annie: How to report on conversions in a way that gives all of the marketing
channels credit for their contribution to the end goal(s). If coaches ran
football teams the way marketers report on conversions, only the players who
score the touchdowns would get paid.
What uninvented technology would improve your life the most?
Avinash: I know this seems silly, but I think I have all the technology I need
in my life. Sure the batteries could last longer and my computer could just type
in what I'm thinking - why do I need to physically type in a cramped plane seat?
There is an impressive amount of technology we need to deploy to ease human
suffering. Those solutions, big and small, from smarter malaria nets to more
precise lasers to target cancer, are the ones I'm rooting for.
Annie: A centralized financial system in the cloud that would enable me to
manage all of my financial needs from one place â from investing to paying
bills to paying my business quarterly taxes â with robust projection and
budgeting data visualizations at my fingertips.
Thank you for speaking with us, Avinash and Annie!
If you would like to read more about Avinash, check out this great interview
he did a couple years ago, which covers some of his views on social media, SEO,
and why he is always looking for exceptional things. You can also follow Avinash
on Twitter @avinash.
Learn more about Annie and web analytics by checking out her info-packed blog,
Annielytics, her great posts on Search Engine Land, and by following her on
Twitter @AnnieCushing.
Even better, get actionable analytics advice by joining us at MozCon and
experiencing their awesome presentations!
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten
hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think
of it as your exclusive digest of stuff you don't have time to hunt down but
want to read!
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/Dlss2ZL9iQo/mozcon-speaker-interviews-avinash-annie
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Avinash & Annie'
Posted by Lindsay
Today I'm excited to bring you a short interview with two of the top web
analytics professionals in the industry, Avinash Kaushik and Annie Cushing. Not
only are they experts at leveraging data effectively, theyâre incredible
conference speakers who are returning to MozCon this year!
Avinash Kaushik is the digital marketing evangelist at Google and co-founder of
Market Motive. He is also the author of two best-selling books, Web Analytics
2.0 and Web Analytics: An Hour A Day, and he writes a popular web analytics
blog, Occam's Razor.
Heâs an energetic speaker who delivers eye-opening insights about the
power of data that you can put into action immediately. He gave an awesome
presentation at MozCon 2011 which inspired a flood of tweets and ended with a
standing ovation.
Annie Cushing is an SEO and analytics consultant. Her areas of expertise are
analytics, technical SEO, and everything to do with data â collection,
analysis, and beautification. Sheâs on a mission to rid the world of ugly
data, one spreadsheet at a time.
If you donât think analytics can be sexy, chances are Annie will change
your mind. She shares practical, actionable information that revolves around one
of her passions â making data sexy. At MozCon 2012, the audience at her
amazing presentation left with tons of useful tips and tricks for creating Excel
spreadsheets that are comprehensive, easy to understand, and compelling to
decision-makers.
We are honored that Avinash and Annie are joining us again at MozCon, and we
hope you will join us, too! Their talks will help you demystify analytics data
the moment you get back to the office.
In his keynote, âSimplifying Complexity: Three Ideas For Higher
ROI,â Avinash will apply Occamâs Razor to three user cases and share
practical tips for dealing with complexity. Annie will show you how to separate
the junk from the sound data when analyzing organic keyword data in her talk,
âBreaking Up With Your Keyword-Based KPIs.â
Recently, Avinash and Annie were kind enough to answer a few questions about
their upcoming MozCon presentations, must-know analytics information, and which
technology would improve their lives.
Tell us about the presentation you have planned for MozCon.
Avinash: My plan is to share three stories that serve as an example of
amplifying the awesomeness of any business not by focusing on doing one thing
well. That seems like such an odd thing to say, but I've convinced that if we
are to make incredible progress we need to solve for multiplicity.
Three simple examples, from our everyday lives, that the audience will be able
to go back and implement in their day to day efforts.
Annie: Iâm going to talk about breaking up with your organic keyword
data. Many marketers (if not most) who focus on organic search are using junk
data that does not stand up to scientific criteria. Iâm going to talk
about what data is junk, how to differentiate junk from sound data, and some
alternatives to junk data that withstand statistical scrutiny.
What is something that all marketers should know about web analytics, but
many donât seem to know?
Avinash: My 10/90 rule. For every $100 you need to invest in making smarter
decisions on the web, you need to invest $10 in tools and consultants to
implement the tools, and you need to invest $90 in big brains to analyze the
data and recommend actions.
People have this insane belief that data talks. No. Data does not talk; people
make data talk.
The question to ask, hence, is not how much data you have. The question is how
many big brains you have.
Annie: How to report on conversions in a way that gives all of the marketing
channels credit for their contribution to the end goal(s). If coaches ran
football teams the way marketers report on conversions, only the players who
score the touchdowns would get paid.
What uninvented technology would improve your life the most?
Avinash: I know this seems silly, but I think I have all the technology I need
in my life. Sure the batteries could last longer and my computer could just type
in what I'm thinking - why do I need to physically type in a cramped plane seat?
There is an impressive amount of technology we need to deploy to ease human
suffering. Those solutions, big and small, from smarter malaria nets to more
precise lasers to target cancer, are the ones I'm rooting for.
Annie: A centralized financial system in the cloud that would enable me to
manage all of my financial needs from one place â from investing to paying
bills to paying my business quarterly taxes â with robust projection and
budgeting data visualizations at my fingertips.
Thank you for speaking with us, Avinash and Annie!
If you would like to read more about Avinash, check out this great interview
he did a couple years ago, which covers some of his views on social media, SEO,
and why he is always looking for exceptional things. You can also follow Avinash
on Twitter @avinash.
Learn more about Annie and web analytics by checking out her info-packed blog,
Annielytics, her great posts on Search Engine Land, and by following her on
Twitter @AnnieCushing.
Even better, get actionable analytics advice by joining us at MozCon and
experiencing their awesome presentations!
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten
hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think
of it as your exclusive digest of stuff you don't have time to hunt down but
want to read!
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/Dlss2ZL9iQo/mozcon-speaker-interviews-avinash-annie
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
[Build Great Backlinks] TITLE
Build Great Backlinks has posted a new item, 'Pyscape: Your Best Friend for
Using the Mozscape API'
Posted by GeoffKenyon
If you do link building and have to pull a lot of metrics from Open Site
Explorer, I would like to introduce you to your new best friend, Pyscape. You
might use a Google Doc to take advantage of the Mozscape API, but this is
better. I promise.
Pyscape, created by fellow Distiller Ben Estes, enables you to pull link data
such as an export of more than 10,000 backlinks or look up Moz metrics for a
bulk URL list. And itâs super-fast.
What does Pyscape do?
When you use Pyscape, you must choose one of the following operating modes to
run:
Metrics: This will simply show all the Moz metrics associated with the given
URL, subdomain, or domain.
Bulk-metrics: This will show you the Moz metrics for a bulk URL list.
Anchor: This will give you all the anchors associated with a URL, subdomain, or
domain.
Top: This will return the top pages on a site.
Links: This gives you a list of links pointing to a URL, subdomain, or domain.
Ose-style: This will return an Open Site Explorer formatted list of links for a
URL, subdomain, or domain.
It is also worth noting that Pyscape does not cut off your reports at 10,000
URLs, and it can be much faster than using the Open Site Explorer Interface
â especially for sites with large link profiles.
Selecting Your Granularity
In addition to telling Pyscape which report you want to run, you need to give
it a little more guidance. This is especially important because Pyscape will
pick an intelligent set of fields to grab from Mozscape based on the options you
specify. Start by telling Pyscape how it should interpret the URL(s) that you
input:
-d (domain): interprets the URL(s) as domains only
-s (subdomain): interprets the URL(s) as subdomains only
-p (page): interprets the URL(s) as the specific pages only
Links Mode
If you are in the links operating mode, here are a few more commands you
should know:
-o (one): will return one URL per linking domain in links mode
-m (many): will return up to 25 pages per linking domain in link mode (this is
the default)
Anchor Mode
Finally, there are a couple more directives you should know if you are going
to use the anchor mode:
-f (phrase): will return anchor text phrases
-t (term): will return term matches (default)
Setting Up Pyscape
So now that weâve covered what Pyscape will do, letâs look at how
we use it. The following steps will take you through setting up Pyscape.
Go to the Pyscape homepage; download the zip file and then extract it.
Enter your Mozcape API credentials (free or paid) in the keys.json file. Get
your credentials here.
Download and install Python, version 3.2 or above (download here).
Go give Pyscape an upvote on inbound.org to say thank you to Ben, or follow him
on twitter.
Running Your First Pyscape Report
Ok, now that weâve got Pyscape installed, Iâm going to take you
through how to run reports using the command line (It sounds technical but
itâs really pretty easy).
Start up the "Command Prompt" application.
Next you'll need to change the directory that the application is operating in
to the directory where you have extracted Pyscape. "Enter "CD" followed by the
folder path leading to the extracted Pyscape directory and hit enter.
Now enter your request. Below are some sample requests that show how requests
need to be structured.
Entering these commands will give you the data you need to start your analysis
in a nice .csv output in lightning-fast time. This Google Doc contains examples
of the output data from Pyscape to help you get a feel for which reports will
best work for you.
The rest is up to you! If you like the tool, make sure to say thanks to Ben
and to vote it up on inbound.org!
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten
hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think
of it as your exclusive digest of stuff you don't have time to hunt down but
want to read!
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/OBxR5VzFyu0/pyscape-your-best-friend-for-using-the-mozscape-api
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Using the Mozscape API'
Posted by GeoffKenyon
If you do link building and have to pull a lot of metrics from Open Site
Explorer, I would like to introduce you to your new best friend, Pyscape. You
might use a Google Doc to take advantage of the Mozscape API, but this is
better. I promise.
Pyscape, created by fellow Distiller Ben Estes, enables you to pull link data
such as an export of more than 10,000 backlinks or look up Moz metrics for a
bulk URL list. And itâs super-fast.
What does Pyscape do?
When you use Pyscape, you must choose one of the following operating modes to
run:
Metrics: This will simply show all the Moz metrics associated with the given
URL, subdomain, or domain.
Bulk-metrics: This will show you the Moz metrics for a bulk URL list.
Anchor: This will give you all the anchors associated with a URL, subdomain, or
domain.
Top: This will return the top pages on a site.
Links: This gives you a list of links pointing to a URL, subdomain, or domain.
Ose-style: This will return an Open Site Explorer formatted list of links for a
URL, subdomain, or domain.
It is also worth noting that Pyscape does not cut off your reports at 10,000
URLs, and it can be much faster than using the Open Site Explorer Interface
â especially for sites with large link profiles.
Selecting Your Granularity
In addition to telling Pyscape which report you want to run, you need to give
it a little more guidance. This is especially important because Pyscape will
pick an intelligent set of fields to grab from Mozscape based on the options you
specify. Start by telling Pyscape how it should interpret the URL(s) that you
input:
-d (domain): interprets the URL(s) as domains only
-s (subdomain): interprets the URL(s) as subdomains only
-p (page): interprets the URL(s) as the specific pages only
Links Mode
If you are in the links operating mode, here are a few more commands you
should know:
-o (one): will return one URL per linking domain in links mode
-m (many): will return up to 25 pages per linking domain in link mode (this is
the default)
Anchor Mode
Finally, there are a couple more directives you should know if you are going
to use the anchor mode:
-f (phrase): will return anchor text phrases
-t (term): will return term matches (default)
Setting Up Pyscape
So now that weâve covered what Pyscape will do, letâs look at how
we use it. The following steps will take you through setting up Pyscape.
Go to the Pyscape homepage; download the zip file and then extract it.
Enter your Mozcape API credentials (free or paid) in the keys.json file. Get
your credentials here.
Download and install Python, version 3.2 or above (download here).
Go give Pyscape an upvote on inbound.org to say thank you to Ben, or follow him
on twitter.
Running Your First Pyscape Report
Ok, now that weâve got Pyscape installed, Iâm going to take you
through how to run reports using the command line (It sounds technical but
itâs really pretty easy).
Start up the "Command Prompt" application.
Next you'll need to change the directory that the application is operating in
to the directory where you have extracted Pyscape. "Enter "CD" followed by the
folder path leading to the extracted Pyscape directory and hit enter.
Now enter your request. Below are some sample requests that show how requests
need to be structured.
Entering these commands will give you the data you need to start your analysis
in a nice .csv output in lightning-fast time. This Google Doc contains examples
of the output data from Pyscape to help you get a feel for which reports will
best work for you.
The rest is up to you! If you like the tool, make sure to say thanks to Ben
and to vote it up on inbound.org!
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten
hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think
of it as your exclusive digest of stuff you don't have time to hunt down but
want to read!
You may view the latest post at
http://feedproxy.google.com/~r/seomoz/~3/OBxR5VzFyu0/pyscape-your-best-friend-for-using-the-mozscape-api
You received this e-mail because you asked to be notified when new updates are
posted.
Best regards,
Build Great Backlinks
peter.clarke@designed-for-success.com
Subscribe to:
Posts (Atom)
