Track the deleted tweets of verified Twitter accounts [Update: not anymore, you can’t]

Update: As expected, PostGhost received a notification from Twitter that the app was in violation of its Developer Agreement and Policy. As such, it was shut down on July 6. Our original follows. Verified Twitter account holders often get stick from other users due to that famous blue tick. The social media ego checkmark, if you will. Well, this tool will delight the frustrated majority who lack such social validation on Twitter. PostGhost tracks all the deleted tweets of any verified Twitter account with over 10,000 followers. It acts as a public archive of deleted tweets from those people Twitter has…

This story continues at The Next Web
Social Media – The Next Web

Does Keyword Research Even Matter Anymore?


Keyword research. I’m sure you’ve done it before.

You probably know what it’s like to use keyword research tools and come up with lists of keywords to track and rank for. I’ve done it dozens of times myself. Why? Because it’s one of those “standard practices” that we do in SEO and online marketing.

But search engines today aren’t looking only at keywords! Search engines are looking at hundreds of different factors. And keywords? They are only a small part of the big picture.

Don’t get me wrong. I think keyword research is still important.

But here’s the thing…

Keyword research isn’t the only aspect you need to be researching when optimizing a website or planning your content marketing.

I want you to go a level deeper—to the level that users are searching for and search engines are indexing for.

I’m going to share with you three ways to go beyond basic keyword research. Although keyword research should still be a part of your SEO, it’s only the start.

I’m confident that these advanced research methods will add rocket fuel to your marketing, attract targeted traffic, earn valuable links, and ultimately boost your revenue.

I will explain in detail how to use each of these powerful research methods.

First of all, let me preface this by revealing something you may not know about Google: the algorithm changes 500-600 times per year.

That’s a rate of nearly 1.5 changes a day!

Even with all the marketing ability I’ve developed running my various businesses, I can’t hope to keep up with the rapid pace of change in the Google search algorithm and its machine learning. Odds are, neither can you.

So, now that you understand the why, let’s dive into the how. This is how we do keyword research in today’s world.

1. User intent

One of the biggest mistakes I see many newbie online entrepreneurs make is that they focus too much on the specific keywords in their research without focusing enough on user intent behind those keywords.

You may be thinking, “Neil, what is user intent, and how do I use it to improve the traffic and conversions on my site?”

User intent is just what it sounds. User intent refers to the user’s ultimate goal in typing a search query.

Let me make a quick point about the terms I am using.

  • Keywords: A targeted phrase you’re trying to rank for. You do keyword research. You use this phrase in your content, making sure it appears in all the right places.
  • Query: The phrase or words that a user types into Google. This could be a short phrase, a question, or just a string of words the user is typing.

I try to keep those two terms—keywords and query—straight, but sometimes I use them interchangeably.

As SEOs, we tend to focus on keywords, right? That’s what we want to rank for, obviously.

But users don’t care about our keywords. They just want to get the best result for their query.

And that’s my point: every query has an intent. Every time someone types something into Google, they are trying to accomplish something. They have a goal.

For example, when I am up late at night watching Gossip Girls reruns and I Google “Chinese food,” my user intent is to order some Chinese food.

And guess what? Google knows this. And, voila, this is exactly what comes up!


However, if I change the wording ever so slightly, typing “great Chinese food” instead of “Chinese food,” what appears is quite different.


By simply changing one word, I shifted the intent of my search from ordering Chinese food to finding great Chinese meals and restaurants in a given area.

See the difference? Sure, the difference involves a change in wording. But the deeper change was one of intent.

Google gets it. The whole search engine is designed to deliver really good results based on the user’s intent.

Check out this video from Google. User intent is the whole reason why Google spends hundreds of millions of dollars to refine its algorithms and enhance its machine learning process.

If the search engine is that focused on user intent, we should be as well.

So, how can you use this to improve your keyword research?

You have to take advantage of user intent to understand which keywords you should try to rank for.

Basically, you need to understand the user’s goal when they input certain queries.

Let me give you another example.

See if you can figure out the intent behind this query: “order a birthday cake”


Pretty straightforward, right?

If this “order a birthday cake” was one of your target keyword phrases, you should understand that the user’s intent is to order a birthday cake.

The great thing about user intent is that it becomes far easier to figure it out as the query becomes longer.

Long queries are really valuable for two reasons:

  • We can identify exactly what the user wants and give it to them.
  • We can gain targeted organic traffic for super-specific long-tail keywords.

Double whammy!

Let me show you exactly what I mean by expanding that “order a birthday cake” query.

Most users don’t simply want to order a birthday cake. They want to order a specific type of cake, for a specific type of person, in a specific location, for a specific purpose, and at a specific time.

See where this is going?

Take a look at this doozy of a query:


How’s that for user intent?

You can use this super-focused intent to create super-focused content!

For this query, you know that:

  • Someone wants to order a cake…
  • for a girl…
  • who is probably between 4 and 10 years old.
  • They don’t want to make the cake themselves.
  • They want it delivered to their venue.
  • And they live in the Atlanta, Georgia, area.
  • Most likely, it’s a mom, dad, or party planner who’s typing in this query.
  • They probably have a limited amount of time on their hands. They’re busy.
  • They live with or know about children and understand what children like.

I could go on and on.

This is the level of keyword research that you want to do. You’re not just spinning a bunch of variations from some keyword tool. Instead, you’re diving into the reasons, the motivations, and the desires of the user.

We could even sketch a persona based on that keyword and then target that persona in our marketing efforts.

Kelly is a 33-year-old working mom. She has a 3-year-old son and a 5-year-old daughter who turns 6 on August 2. Kelly loves her kids but isn’t able to spend much time with them because of her demanding job as a paralegal in downtown Atlanta. Kelly wants to surprise her daughter with a special birthday party with a princess theme.

You might not be able to achieve this level of research for every keyword, but you can at least get a general idea of the general intent of your target audience.

Basically, if you know why a user is looking up a certain keyword, you will be able to determine what keywords you want to use on your website and in your content.

Using my first example, if you were a Chinese takeout restaurant, you would want to rank for “Chinese food,” “order Chinese food,” or “Chinese takeout.” Ideally, you would also try to rank for local terms such as “Chinese takeout downtown Las Vegas.”

However, if you ran a Chinese recipe niche site, you might try to rank for “great Chinese food,” “awesome Chinese recipes,” or something similar.

2. Search query type

Another important element of diving deeper into keyword research is understanding search queries and search query type.

As I explained above, a query is what a user types into Google. A keyword is what you’re trying to rank for.

Let me show you a keyword and a query example so you can clearly see the difference.

Keyword: Men’s skinny jeans

Query: Where to buy men’s skinny jeans

Do you see the difference?

The keyword is a relatively straightforward term. The query, however, is more specific because the user wants to accomplish something (user intent—as discussed above).

But there’s another remarkable thing about those queries.

Whenever you are doing keyword research, try to understand what kind of queries lend themselves to people hitting the “buy now” button.

It’s really important because if you could figure out the types of queries that lead people to purchase immediately, you would be able to get more sales.

And if you could figure out the queries that pulled people into the top of your funnel, you’d be able to structure an amazing content marketing campaign.

Here is the good news: you can find that out, and you can structure your content marketing around those types of queries.

Here’s how.

There are three basic types of queries:

  1. Informational
  2. Transactional
  3. Navigational

Let me explain each of these so we can get clear on how to target each one:

  1. Informational searches are pretty easy to figure out. The user wants to get information on a certain topic. For example, “how to structure a content marketing campaign” is an informational query.
  2. Transactional searches mean that the user is trying to buy something or transact in some way. “Buy skinny jeans online,” “order flowers las vegas,” or “whole foods coupon” are all transactional queries.
  3. Navigational searches take place when the user is trying to get to a specific website but doesn’t remember or doesn’t want to type in the URL. For example, if I wanted to visit the Men’s Health website, I would search for “mens health” or “mens health mag” rather than typing “” into my search bar.


Nearly every query fits into one of these three types.

What’s even better is that nearly every query has a specific position in the marketing funnel.


Make sure you understand, of course, that most search traffic is informational.


In other words, you’ll be gaining most of your leads in the top of the funnel through informational queries.

Informational queries build awareness and aid the user’s consideration, just like the marketing funnel predicts.


Let me share an example now so you can see how to apply this information to your content marketing and SEO strategies.

Say you are selling men’s skinny jeans and trying to decide which keywords to try to rank for.

Some possibilities:

  • Men’s skinny jeans
  • Top men’s skinny jeans
  • Skinny jeans men’s style
  • Best men’s skinny jeans
  • Distressed men’s skinny jeans
  • Hipster men’s skinny jeans

Now comes the important part of understanding the search query.

If you were an e-commerce store that sold men’s skinny jeans, the keywords you would try to rank for would be very different from the ones you would target if you were running a blog on men’s fashion and writing an article on why skinny jeans are appalling.

This is the difference between informational and transactional search queries.

Basically, you want to research search queries related to your industry to discover new keywords you can try to rank for.

Let’s say you are selling men’s skinny jeans. You want transactional queries. Looking at the different search queries, you will notice that common keywords that pop up are:

  • Men’s skinny jeans sale
  • Men’s skinny jeans online shopping
  • Men’s stretch skinny jeans

Within an e-commerce environment, it’s important to understand the specific nature of a user’s transactional query. They might be looking for sizes, features, and specific product types.

Most e-commerce search functionality offers support for “non-product” queries but has limited ability in allowing “subjective” queries.


By enhancing keyword support in the most relevant areas of your e-commerce website, you’ll be able to gain organic traffic to those internal pages where the user is prepared to transact.

If, on the other hand, you run a fashion blog and are writing that article on men’s skinny jeans, you might find search queries like these:

  • Fashion blog men’s skinny jeans and boots
  • Men’s skinny jeans outfits
  • Men’s skinny jeans
  • Spring outfits men’s skinny jeans

As you can see, all these queries contain the keyword phrase “men’s skinny jeans,” but the secondary keywords you should try to rank for will change based on the user intent behind the search query.

By knowing which queries you are targeting, you will be able to come up with a more targeted list of keywords to try to rank for.

Plus, the keywords will result in greater conversions of your visitors into either blog subscribers or buyers.

3. Demographic research

The third and final part of keyword research is demographic keyword research.

You know about demographics, right?

Demographic research is a powerful marketing tool. You can use the information you gain in your demographic research to target specific types of people.

You’ve probably seen sample personas like this one:


Most personas contain demographic data:


In the persona above, it’s helpful to know that Brandi…

  • is a female
  • is 36
  • lives in the LA area
  • makes 38k a year
  • has narrow feet

Personas affect everything in marketing.

Personas affect keywords too.

Let me show you how.

Let’s say your target demographic is men ages 18-35 looking to lose weight.

However, you’ve chosen to target the keyword “easy fat loss.”

What you may find is that the majority of people searching for “easy fat loss” are women 30-45. (I’m just using this as an example, so this assumption may or may not be true.)


Thankfully, there are several excellent tools you can use for keyword demographic research, including Microsoft’s AdCenter Labs, Keyword Discovery, and, of course, the AdWords’ Keyword Planner.

Some of these tools, such as Keyword Discovery, are particularly structured to enable demographic keyword research.


The more you can segment and analyze your data, the better you will become at identifying demographic keyword trends.

A report like the one below, for example, alerts you to the fact that men and women between the ages of 35 to 54 search for “oscars” at specific times of day.


The demographic information behind some queries is obvious.

  • Men’s skinny jeans. The demographic is most likely young men.
  • Amazon books for teenage girls. This demographic could be either a teenage girl or the parent of a teenage girl.
  • Best foods for pregnancy. Probably a mom-to-be.

By using the right research tools and figuring out which queries your ideal demographic is typing, you’ll be able to be more precise about the keywords you try to rank for.

Here’s a parting word of advice about demographics: narrow it down.

We would all like to think that our product is good for everybody. However, if you can identify your ideal client and demographic and really capitalize on this, making sure every keyword you rank for is something that demographic is searching for, you’ll have a higher conversion rate than if you went too broad with your keywords.

Specific, long-tail queries will draw in the specific and eager customers you want to attract.


Here is what you need to know: Keyword research still matters. It is an integral part of any successful online business.

But basic keyword research on its own will not get your as far as you need to go with your online marketing! Your standard practice of typing a few phrases into Google Keyword Planner and exporting the list into your tracking software isn’t how it’s done anymore.

You have to be willing to dive deeper into your research to uncover the who, what, and why of each of your keywords.

If you can go beyond the basics, you will improve your marketing success.

I’d love to hear about any innovative strategies you know that take keyword research to an advanced level. What methods do you use to go beyond basic keyword research?

Quick Sprout

The Debate Around “Do We Even Need CSS Anymore?”

This has become quite the hot topic lately. It’s been talked about at a number of conferences and meetups I’ve been at personally lately. I’ve seen slide decks on it. I know people literally not shipping any CSS in production. Pretty wild, eh?

I thought we could have a little campfire here and talk about it as rationally as we can, covering all the relevant points.

We obviously still need to style things

Nobody is saying we don’t need styles. We still need to style things, what’s being talked about is how and where we do that. I was just on a panel at BrooklynJS and Jed Schmidt said:

The worst things about CSS are the “Cascading” and the “Sheets”

What does anyone have against CSS?

These are the main arguments against CSS:

  • Everything is global. Selectors are matched against everything in the DOM. You need naming strategies to combat against this and keep things efficient (which are hard to enforce and easy to break).
  • CSS grows over time. Smart people on great teams cede to the fact that they are afraid of their own CSS. You can’t just delete things as it’s so hard to know if it’s absolutely safe to do that. So, they don’t, they only add. I’ve seen a graph charting the size of production CSS over five years show that size grow steadily, despite the company’s focus on performance.
  • You can be more dynamic with styles in a programming language. The argument goes something like “we’re already juicing up CSS with preprocessors anyway, might as well kick it up a notch.” You could for instance (if you really wanted to make this controversial) base styles off a User-Agent string or a module’s current width.

What is the alternative to CSS then?

The alternative is inline styles. So instead of:

<div class="module">

We’re talking:

<div style="padding: 20px; background: #eee; margin: 0 0 20px 0;">

I haven’t heard anyone yet argue you should apply these styles directly to HTML you author. The idea is you apply styles to elements through JavaScript.

React is driving a lot of these thoughts

React is a JavaScript library that helps with view concerns in websites. It’s developed mainly by Facebook, extremely popular, and gaining momentum. It’s had it’s own conference and is even growing into a framework for building native apps.

One of it’s core concepts is the “Virtual DOM”. You build the HTML you intend to use right in the JavaScript. Seemingly quite weird at first, but this coupling between HTML and JavaScript is always there and it appeals to people to just write it together from the get-go. I quoted Keith J Grant recently, and I will again:

This coupling is real, and it is unavoidable. We must bind event listeners to elements on the page. We must update elements on the page from our JavaScript. Our code must interact bidirectionally and in real-time with the elements of the DOM.

… the mantra of React is to stop pretending the DOM and the JavaScript that controls it are separate concerns.

React has the ability to manage inline styles built right in. They call them what they are: inline styles. Here’s a basic example:

See the Pen Inline Styles with React by Chris Coyier (@chriscoyier) on CodePen.

The virtual DOM thing that React does is also important because of its speed. DOM manipulation stuff is generally regarded as slow in JavaScript, and thus managing styles through DOM manipulation would also be slow. But React has the magic dust that makes manipulation fast, so people don’t worry about the slowness issues when working with React.

Here’s another example by Chris Nager.

The style authoring is still abstracted

CSS is the abstraction of style away from anything else. Literally files you open and work on to manage styles. You likely aren’t giving that up when moving to a JavaScript-based inline-style setup. You’d just have, probably, `style.js` instead of `style.css`. You’d still be writing key/value pairs and smooshing files together in a build process.

It will be different, but the authoring abstraction is still there.

What do you get out of inlining styles?


The scary “global” nature of CSS is neutered. The cascade, tapered. I don’t think you could say the cascade is entirely gone, because some styles are inherited so styles can still be passed down to child elements and that’s one definition of cascade. But the module-ish nature of this style of development likely leads to less overlapping style concerns. A module over here is styled like this, a module over there is styled like that – probably no conflicts in sight.

All JavaScript

One sense I get is that some people just like and prefer working in all JavaScript. You could certainly attribute some of the success of Node.js to that fact.

Dynamic Styles

“State” is largely a JavaScript concern. If you want/need style to change based on dynamic conditions (states) on your site, it may make sense to handle the styling related to the state change along with everything else.

In a recent talk at CSS Conf (slides), Colin Megill used the example of the Twitter new tweet input textarea as a dynamic place that changes the state of other elements.

Who’s actually doing this?

I heard Colin Megill say they are shipping literally zero CSS on “big stuff” and not seeing performance problems. I’ll update this with URL’s if I get them. I hear one big project will be live within a month.

I know Jed Schmidt works on the mobile version of UNIQLO, and you can see the inline styles at work there:

Update from Jed: This version of the site is all Sass and the inline styles you see there are from JavaScript animations.

Christopher Chedeau has been talking about this and is literally a Facebook engineer, so maybe Facebook a little?

Can this concept be combined with, you know, CSS?

Even if you bought into the concept of inline styles, can it live in harmony with some (do I have to say it) regular CSS? Is page layout appropriate as inline styles? Doesn’t base typography still make sense to do globally? I’m not sure if we’re far along enough in this world to see a best practice emerge.

In the example above, they are shipping a 57k CSS file as well, and you can see evidence of state-based class in the DOM as well (e.g. “is-open”).

A lot of people really don’t like this

Surprise! There are more arguments against this kind of thing than for it. As I was collecting opinions about this, I told Lea Verou “Some people really like this idea!” to which she told me:

You can find people in the world who like eating excrement it doesn’t mean it’s a good idea.

Let’s run through other arguments:

Styling is what CSS is for

This is the “religious” angle that probably isn’t going to take us very far.

The separation of concerns is inherent to CSS

Separation of concerns is a very useful concept when building things as complex as websites are. You get seperation of concerns automatically when writing CSS: it’s a file just for styling.

Inline styles are at the top of the specificity spectrum

Keeping specificity low in CSS means that when you do need to rely on specificity to win a styling war, you have it available as a tool. When you’re already at the top, you don’t have that wiggle room luxury.

The !important declaration can still win a specific property/value styling war over an inline style, but that’s a slightly different concept and an even grosser war to fight.

Some simple states are much easier in CSS

How do you do :hover/:focus/:active in inline styles? You don’t. You fake it. And what about media queries?

Adding/removing classes is a perfect tool for state changes already

JavaScript is really good at adding/removing/changing classes on elements. And classes are a perfect way to handle state in CSS.

.is-open {   display: block; }

Plus you can change state on parent elements (by changing a class) to affect the state of lots of elements within:

.tweet-too-long {   .tweet-button {     opacity: 0.5;   }   .warning-message {     display: inline-block;   } }

Browsers aren’t made to deal with styling in this way

For instance, inline styles are literally data kept in an attribute right on the DOM element. DOM weight is a thing (it can cause browsers to be slow or crash). That styling information isn’t only just kept in the style attribute though, it’s also represented in the DOM in the element’s style properties. Is that the same thing, or is this kinda double-weighted styling?

Are there speed differences between…

var thing = document.getElementById("thing"); = "100px"; = "100px"; = "red";  var thing2 = document.getElementById("thing-2"); thing2.setAttribute("style", "width: 100px; height: 100px; background-color: red;");

Has that been figured out to discover what’s best cross-browser? If this stuff takes off, will browsers need to evolve to handle things in a different way?

The browser has this whole concept of the CSSOM. Can we use that somehow more intelligently through JavaScript rather than inline styles?

CSS is successful because of it’s simplicity

CSS is a fairly easy to jump into. A lot of people know it. You can hire for it. It’s portable.

Some of these “dynamic” styling concerns can be solved with regular CSS

  • There are demos that include measuring widths and subtracting fixed values from them. CSS can do that with calc().
  • There are demos that include setting font-size or line-height that depends on the browser width or height. CSS can do that with viewport units. Using JavaScript for this kind of thing is overtooling.
  • There are demos that dynamically change colors on many different elements. CSS will be able to do that with native variables.

We tried this in 1996 and it was a bad idea then

Get off my lawn.

CSS is cacheable

The network is still the bottleneck. CSS files can be cached so the network doesn’t even come into play and that is smoking fast.

You can still use React

React is pretty awesome. Here’s an article by David Khourshid on Styling React Components in Sass. Mark Dalgleish doesn’t like the global nature of CSS, and has working concepts to localize selectors. Glen Maddern expounds upon this in Interoperable CSS.

Doesn’t anyone care about progressive enhancement anymore?

This is a wider conversation is perhaps out-of-scope here. Because sites (including React based sites using inline styles) can be rendered entirely server-side, it means they can be done with progressive enhancement in mind. Although “can be” and “what it actually encourages” are different things.

The Debate Around “Do We Even Need CSS Anymore?” is a post from CSS-Tricks