3 Common SEO Mistakes

Ranking your web pages on search engines are usually the foundation to any digital marketing strategy. Unfortunately, most people don’t know how to properly execute a solid SEO plan. This article is meant to provide you a quick and easy list that addresses the top 3 SEO mistakes and how to fix them.

SEO Mistake #1: Duplicate Content

Duplicate content is one of the most seen problems with a website’s SEO. Webpages are considered duplicate if they contain identical or nearly identical content. Excessive duplicate content may confuse search engines as to which page to index and which one to prioritize in search results. Using duplicated content across multiple pages may lead to traffic loss and poor placement in search results, and it may even provoke search engines to ban your page. Keep in mind, duplicate content can obviously be due to writing the same content on various pages, but it can also result from duplicate pages or internal issues.

How to fix duplicate content:

  1. Provide unique content on the webpage.
  2. Remove duplicate content.
  3. Add a rel=”canonical” link to one of your duplicate pages to inform search engines which page to show in search results.

SEO Mistake #2: Duplicate and missing meta-descriptions

A meta-description tag is a short summary of a webpage’s content that helps search engines understand what the page is about and can be shown to users in search results. Duplicate meta descriptions on different pages mean a lost opportunity to use more relevant keywords. Also, duplicate meta descriptions make it difficult for search engines and users to differentiate between different web pages. It is better to have no meta description at all than to have a duplicate one.

How to fix duplicate and missing meta-descriptions:

  1. Remove duplicate meta-descriptions and provide a unique description of the page
  2. Provide a unique, relevant meta description for each of your webpages.

SEO Mistake #3: Low text-HTML ratio

Your text to HTML ratio indicates the amount of actual text you have on your webpage compared to the amount of code. This warning is triggered when your text to HTML is 10% or less. Search engines have begun focusing on pages that contain more content. That’s why a higher text to HTML ratio means your page has a better chance of getting a good position in search results. Less code increases your page’s load speed and also helps your rankings. It also helps search engine robots crawl your website faster.

How to fix low text-html ratio:

Split your web page’s text content and code into separate files and compare their size. If the size of your code file exceeds the size of the text file, review your page’s HTML code and consider optimizing its structure and removing embedded scripts and styles.

In Conclusion

There are a significant number of other issues that can arise when optimizing your site for search engines, but begin addressing the one’s mentioned above and you’ll notice a difference. Just remember to take your SEO fixes one step at a time. Patience will go a long way when it comes to SEO.

If you don’t have these 4 things, you need a new website.

Online shopping has become one of the easiest and efficient ways to shop. That’s why more and more people are going online to look for products and services rather than going to a physical location. That means your company’s website is crucial to keep up with the times and capture your consumer’s business.

First impressions are everything

I’m sure you’ve heard that expression before. The same goes for your website. Consumers need good experiences so if someone goes to your website and it looks outdated or they can’t find anything, they will more than likely go somewhere else. You may not be hearing complaints about your website, but that doesn’t mean there’s not a problem. If you had an updated website, you could be getting even more traffic, leads, and sales. What we tell customers is to redesign your site every 2-3 years with periodic updates to ensure you’re giving your customers exactly what they want: content, user-experience, and appealing design.

Is your website optimized for mobile?

If not, you need a new website. Something to keep in mind is the importance of mobile. Whether you’re a manufacturing company or a retail company, your customers have phones. There are a vast number of searches every day on mobile devices so that means your site must be designed as such. Responsive design for mobile devices will ensure your consumers have a good experience wherever they look at your website and services.

Is your site SEO capable?

If not, you need a new website. Search engine optimization, or more commonly referred to as SEO, is where your site will appear on search engines. Consider this, you have a solid website, enticing brand messaging and a cool logo, but your website isn’t optimized so no one will ever find you to even see that. That makes all your previous efforts meaningless. Having a site that is ready for SEO is huge so if you don’t have a site that gives you that ability, you are already way behind the game.

Does your website take forever to load?

If so, you need a new website. If your site is slow, your rank on Google will be drastically lowered. Not to mention, people want things exactly when they want them. If your page takes forever to load, people will bounce off your site and onto your competitor’s.

Can you link social media on your website?

If not, you need a new website. We mentioned people go to your website to look at your services and may look up your website on their mobile device, but we haven’t talked about the power of social. A large number of people also want to know what other people have to say about you and whether they want to do business with your company. That means they may go to social platforms to make their decision. It’s important to be on social to funnel your potential customers back to your website. If you aren’t on social, that’s an opportunity to gain even more business, but if you are on social and don’t have a website that links with them, that’s just as bad!

Final Thoughts

There are plenty of reasons to update or get a new website, but if you don’t believe us, just look at your competitor’s website. Technology is always changing and so is the way people do business. If you want to ensure your business is future-proof and continues to do solid business, you may want to consider updating your website.

Remember dingbats?

They’re the fonts that come preloaded on most computers, made up of hand gestures, zodiac signs, and tech dinosaurs like floppy disks and cassette tapes. (Windows’ version is called Wingdings.) They were used for…actually, I have no idea. Sending secret messages in code, maybe?

Well now, dingbats are all grown up. And believe it or not, they’re an important part of any modern web designer’s toolkit.

Say it with icons

We’ve talked a lot about responsive design here. But there’s one piece of the puzzle we have yet to address: how to deal with icons. The most obvious move might be to upload an image of the icon you need—say, a shopping cart to represent your online store, or a gear to link to your settings menu.

But image files are clunky. They get pixelated on larger displays. They don’t always size correctly. One option is to use a vector to ensure consistency across screens—but these tend to be large files, and can slow down your site if you have lots of icons to display.

So, what’s the solution? Over the past few years, many web designers have made the transition to icon fonts. Says The Next Web, think of icon fonts as a grown-up version of dingbats—with an actual purpose. These font faces are made up of the symbols we see all over the web every day: tiny speech bubbles, which we now associate with commenting features. Lock icons meant to suggest security. Miniature trash cans that allow us to scrap whatever we’re doing and start over.

Without even meaning to, we’ve all learned the “language” of these icons. When we see a picture of an envelope or a calendar page, we know what to expect. And fortunately for web designers, you don’t have to start from scratch when you need icons to use for your own site. There are plenty of font libraries out there—some of them available for free. Many of these fonts even contain logos for social platforms, like the Facebook “f,” Twitter bird, and Google “g.”

Good for users, good for you

Why else do icon fonts trump images? Chris Coyier at CSS-Tricks gives a great explanation. With just a few deft change to your code, you can change icons’ size and color, add shadows, use transparent knockouts, rotate, and more.

Plus, icon fonts’ minimalist, no-frills look is right in line with what’s popular in design right now (think Windows 8 Start menu icons or Apple’s new iOS).

Getting started with icon fonts is pretty simple. Download the font packs you want, then use the “data-icon” attribute to tell your CSS how you want icons to behave. You can take this a step further to be sure icons are interpreted correctly by screen readers—more on that here.

You can also use a service like IcoMoon, which allows designers to create one-of-a-kind icons (or use IcoMoon’s own), then store them remotely on IcoMoon’s servers. Then, you can swap out icons easily, without having to change your CSS.

This might sound complicated, but once you get the hang of using icon fonts, you’ll wonder why you ever bothered with pesky jpegs and vector files. Your site visitors will see faster loading times and great displays on any screen.

Sometimes icons speak louder than words. Need help integrating them into your site? Give Atomic a call today.

Imagine your toughest class in college. You had a choice: take notes and study throughout the semester—or wait until the last minute to cram before the final exam. Studying little by little might have taken up time when you’d have rather been out with friends. But by the time the final rolled around, you had a bank of clean, organized notes to use as a study guide. You probably sailed through the exam, no problem.

Or you went the other route. Skipped assigned reading and blew off study sessions. Left the hard work for when it really counted: finals week. Problem was, since you weren’t building knowledge and checking your understanding over time, you didn’t even know where to begin. You were starting from scratch—and between caffeine-fueled all-nighters and potential nervous breakdowns, you spent the same amount of time at work as the person who studied all along (although your final grade might have said otherwise).

I won’t ask which student you are in this scenario—but it’s pretty clear which is the better strategy, right? Put in a little extra effort now to make life easier later.

This is a lot like the choice developers have to make between unit testing and overall testing of their code.

Unit testing: Getting down to the nitty-gritty

Unit testing means isolating the smallest possible elements of a program’s source code, then testing them one by one to be sure they work like they should. It’s different than the overall testing you probably do just before releasing software, which simply tests that a program behaves correctly.

With unit testing, if there’s an error anywhere in the program, you don’t have to work back through all of your code to sniff it out. You can see which test failed, and from there, isolate your error and make a quick fix.

One of the more popular unit testing tools out there is PHPUnit, used to test code written in PHP. PHPUnit saves all of the unit tests you’ve previously written, making your code easier to maintain over time. (Think of unit tests like lecture notes you can refer to before a big exam.)

Just say “no” to skipping unit tests

Surely this is a part of every developer’s coding toolkit, right? Not exactly. Just like some students choose cramming over studying in chunks, many developers shrug at the idea of unit-testing their code. Why? Chris Cornutt at Sitepoint offers a few reasons: They think it takes too long. Or that their code is fine the way it is. Or that it’s just plain boring.

Those things may be true. But think about the alternative: You’re down to the wire and ready to send a program to a client—and you discover a bug. You have no way to figure out when or how it popped up, nor any way to verify exactly which parts of your code it affects. Better hope you’ve got some Red Bull handy, because you’re in for a long night.

Refactoring without tears

The other great thing about unit testing is that it makes major code changes, or refactoring, a breeze. For many developers, refactoring can feel like playing Russian roulette with your code. You don’t want to make too many changes for fear of undoing your hard work.

But if you’ve been adding unit tests to your test suite all along, refactoring is no big deal. Simply update your code, and then run your old unit tests against the changes you’ve just made. If any tests fail, you know exactly what to fix.

It’s the surest way to get your clients to give you an “A.”

Still not convinced that unit testing is the way to go? Learn more about PHPUnit here, or listen to this talk by Professor Richard Buckland on why smart programmers test in units.

Need code that works right, every time? Contact Atomic for help with your next web development project.

Like any good web designer, I know CSS like I know my ABCs. CSS (short for Cascading Style Sheets), along with HTML, is the foundation of so much we do as developers. But I’m here to tell you that there are better ways to code.

Imagine you’re an artist. You’re asked to draw a picture of a sunset, but all you get to work with are some gray paint and a thick, messy brush. You’ll work with what you’ve got—but even if you’re da Vinci, your painting won’t be as good as it could be. To really work your magic, you need better tools (for starters, a few colors would be nice).

This is a little bit like Sass’s relationship to CSS: Sass is a stylesheet syntax that works as an extension of CSS3. It offers a bunch of handy features that make coding faster, cleaner, and more, well, colorful.

Sass first appeared in 2007. It’s short for Syntactically Awesome Stylesheets (seriously), and has two syntaxes:

• Indented syntax. This is the older, rarer Sass syntax. It was inspired by bare-bones coding languages like Haml, and uses line indentation rather than brackets or semicolons to separate blocks. Indented syntax files go by the extension .sass. The problem with this syntax is that it’s not compatible with CSS, and doesn’t look much like it, either. This makes indented syntax tougher for designers to learn and use.

• Sassy CSS (SCSS). This is the most commonly used form of Sass (introduced in Sass 3.0), and uses the file extension .scss. It works like an add-on to CSS3, meaning that every stylesheet that’s valid in CSS3, is valid in SCSS.

Whichever syntax you choose, think of Sass as CSS3 taken to the next level. Those tedious, repetitive features of CSS that you hate? Chances are, using Sass makes them simpler. Sass offers features like:

• Nesting. When you’re writing code for elements with many sub-components, like tables or lists, typing the same selectors over and over can get old fast. Sass helps you avoid this headache by nesting child selectors inside parent selectors. You can also apply nesting to properties of a given selector, like font or border attributes.

• Variables. You can use Sass variables to describe attributes of selectors that you plan to reuse. Variables are called out using the symbol “$.” Let’s say you want all text to show up in a shade of light blue, but don’t want to keep track of the color’s hexadecimal code.

First, write what you want your color variable to represent:

$lightblue: #00CCFF;

Then, apply that variable to your text:

$textcolor: $lightblue;

Variables are lifesavers on big, long-term projects. Rather than committing styles for colors, links, buttons, and tables to memory, write easy-to-remember variables into your code.

• Mixins. Mixins take variables a step further by allowing you to use a single selector to represent a whole section of code (for example, all style elements of a table). You can even add in equations to instruct an element to adjust sizing as needed. Sass also supports conditional states and “for” and “for each” loops. Best of all, mixins are automatically removed from your code when you compile, so they don’t affect file size. Check out Compass for a great library of reusable, open-source mixins.

Intrigued yet? This is just a sampling of what Sass can do. If you’re ready to add some Sass to your code, head here to learn how to install (it’s written in Ruby). And be sure to check out the developers’ complete Sass Reference Guide, which contains everything you need to know to make your stylesheets syntactically awesome.

Upgrading to Sass from CSS3 is like switching from dingy gray paint to a 64-color Crayola box. Once you get the hang of it, you won’t know how you ever did without.

Want to know more about coding with Sass? Atomic’s developers can give you the inside scoop.

 

So, you’ve got a great design idea for a new website, and you’re ready to take it to a developer. Or so you think. The developer looks at your mockups, and he’s got a few questions. Will it use jQuery for animations? How will drop-down menus behave? What will be your links’ hover states and rollover styles?

If your answer to these questions is, “uhhh…” (or anything similar), listen up. If you’re designing for the web, it doesn’t matter whether you’re doing the actual coding. Knowing at least a little about the world of web development is now officially part of your job.

Your design files should allow a developer to easily pick your design apart, build it, and take it live. To do this, you need to speak developers’ language—so you can explain exactly what you want them to do.

Why’s this so important? Because if you aren’t clear about how you want things to look, certain features won’t be built into the live site. (I learned this one the hard way.) But knowing the basics of web development means you can communicate clearly. And that will make your life—and the developer’s life—a whole lot easier.

At a minimum, here’s what you need to know.

• Get some basic CSS3 know-how. Gradients, buttons, drop shadows, and even basic shapes and rounded corners can be built with CSS. And using CSS instead of images cuts down on the size of a site—meaning faster loading time. Design visual elements that can be reproduced in CSS (rather than creating clunky image files), and developers will thank you for it.

• Use standard fonts. Choose fonts from Typekit, Google Web Fonts, or another major font directory. Again, if you choose a font that isn’t common on most browsers, your type will have to be displayed as an image, meaning slower loading times—and frustrated developers.

• Go easy on the backgrounds. The same goes for webpage backgrounds. Go for a solid color—or a small image or texture that can be easily repeated. This will also help cut loading times.

• Be careful with images. If you’re a designer, Photoshop is probably your thing. Here’s a tip for sharing images with web developers: Use the Pen Tool to cut out all images that will need a transparent background, instead of using blend modes. If the developer goes to save the image and you used a blend mode, it’ll show up on the live site with one of those ugly, patchy backgrounds. Don’t let this happen to you.

• Keep responsive features in mind. As some screens get bigger, while others get tinier, you need to make sure your design can easily adjust to different browser sizes—or appear in a totally different configuration based on the device it’s viewed on. So make sure design elements can be resized easily or simplified for faster viewing on mobile platforms. But don’t forget a high-res photo for full-width banner images—that way, it won’t get pixelated if viewed on a huge screen.

And where can a designer learn development basics—fast? You can’t learn to code overnight, but sites like Codecademy and Smashing Magazine are a great place to start. Another cool trick I’ve learned: find a site you like, and peek at its code using the Inspect tool in Chrome or Firefox. Just right-click on an element, click “Inspect,” and voila—learn any site’s coding secrets!

Soon, you’ll be throwing around terms like “cell padding” and “pseudo-class selectors” with ease. And you’ll be happy seeing your design creations come to life—just the way you imagined them.

Want to see what our designers are capable of? Contact Atomic, and we’ll give you all we’ve got.

 

Clients often tell me that they think their sites scroll too much. “People are too lazy to scroll,” they say. “We want all of our most important content visible at once.”

I hear what they’re saying. Designing “above the fold” used to be huge in web layouts. But unless you’re still living in the early 2000s, this way of thinking just isn’t relevant anymore.

Designing above the fold means content has to fit in a space the size of your computer screen. That seriously limits design options—and can make your site look crowded as everything gets tinier and tinier to fit. Exactly how much space do you have to work with? That’s hard to judge, too, considering the countless screen sizes, resolution levels, and devices someone might want to view your site on.

I’m not saying you should load down your sites with never-ending blocks of text. The new generation of scrolling sites uses movement to tell a story. They’re perfect for introducing a new company or product: you can walk users through what your product does and how it works, then lead them right where they need to go to learn more—or better yet, buy. These sites are animated—but they require viewer interaction in order to come to life. Check out these examples to see what I mean:

http://www.zensorium.com/tinke/

http://www.milwaukeepolicenews.com/

http://a-class.mercedes-benz.com/com/en/index.html

Sites like these seem like they’d be complicated to build, but they’re really not: most of the effects you see can be created using just jQuery and CSS (get started with a framework like Blueprint or Foundation). Like any new trend, scrolling sites have their kinks: some techniques are only supported in current modern browsers, and adjustments have to be made for mobile displays.

But personally, I’m excited about what scrolling sites have to offer. I could click around sites like these all day and never get bored—they’ve got the power to hook even the laziest of web surfers. And I keep going back to show other people how awesome they are. As a developer myself, I know that’s music to a site creator’s (and client’s) ears.

Is your site trapped in a scroll-less rut? Contact Atomic, and we’ll help you set your site free.

A few years back, I was working as special projects manager for the City of Dayton. The city needed a firm to take on a unique assignment: creating a website for the Ohio Aerospace Hub. Dayton earned the Hub title in 2009, an initiative to draw aerospace-related jobs, education, and economic development (read: cash money) to the region.

Researchers partnering with the Ohio Aerospace Hub are up to all kinds of crazy stuff: advanced sensing, drone technology, cybersecurity, you name it. The Hub needed a website to show off its research to the world.

But the website had to do more than just inform. The Ohio Aerospace Hub will require significant investment over time—not to mention an A-team of scientists and engineers to get things done. Now, we locals already know how cool Dayton is. But the city wanted to raise its profile by attracting a new segment of people: techies, creative types, entrepreneurs, and businesses keen on Dayton’s new aerospace economy. That’s a tall order for one little website—but Atomic was up to the task.

In the search for the perfect firm for the job, Atomic really set themselves apart. (It also led to my job here—but that’s a different story.) Throughout the development process, there was great collaboration between the guys at Atomic, the director of the Hub, and all of the partners involved. The result: an awesome site—that got people talking as soon as it launched.

And it’s not just Daytonians taking notice. International publication fDi Magazine held its first annual Digital Marketing Awards in 2012, sizing up economic development sites worldwide on design, innovation, and social media strategy. More than 50 organizations entered the contest. The Ohio Aerospace Hub won 12th among websites overall, and third among Economic Zones, a category for initiatives within a city, state, or country.

I’m proud of what our team has accomplished. Now, Atomic is ready to help the Ohio Aerospace Hub move forward as its research products take flight. (Plus, maybe they’ll finally let us give their latest gadgets a try. Fingers crossed.)

We can’t wait to see what the Hub does next.

We’ve talked a lot lately about responsive web design—and if you’ve been paying attention, you know it’s an innovation we’re pretty excited about. As Atomic’s new web development manager, I’ve noticed something else: responsive design has changed the designer-developer relationship.

It used to be that a graphic designer would create a finished Photoshop document depicting his or her vision for a site. The developer’s job was to make the site match the doc, pixel for pixel. In design school, you’d lose points for wrongly-sized columns or incorrect text. And if you were a professional developer, the consequences weren’t any friendlier.

Now, things are different. As Web platforms, screen sizes, and resolution types multiply like rabbits, a layout that looks great on one screen might not look so good on another. This means that designers and developers alike have had to learn to compromise.

Designers have to accept the fact that their designs aren’t going to be exactly the same form one viewport to the next. And developers have to realize that they can’t build a unique site for every device—coding time and costs would be way too high.

Another downer for developers: with the number of screen sizes out there, we have to give up on pixel perfection. Why? Responsive designs use percentages, rather than fixed widths, to tell browsers how to display websites. For ensuring a consistent look from one screen to the next, this is great. The problem is that when percentages aren’t expressed as whole numbers, browsers get confused. The number ends up getting rounded either up or down, meaning that sites don’t always display the way we plan. But fortunately, most of these rounding errors are usually only obvious to other keen-eyed developers.

So yes, responsive design has created some bumps in the road. But ultimately, I think it’s led to a more collaborative relationship between style-minded designers and code-bound developers. Designers still bring the initial creative force with a site mockup. But developers don’t have to follow it blindly: they’ll create a beta site, and we’ll test it on different devices to make sure all of the responsive elements work. The designer comments; the developer tweaks. We’ll go through as many iterations as we need until both sides (and of course, the customer) are happy.

And when my team’s happy, I’m happy.

Need a site that looks great on every screen? Call up Atomic and we’ll make it happen—no matter how many trials it takes.

When Apple rolled out the Retina display-equipped MacBook Pro earlier this year, the world oohed and aahed at its eye-popping renderings of nature photographs and smiling stock photo models. Meanwhile, web developers everywhere did a collective facepalm.

‘Retina’ quality devices are said to have such high pixel quality that at a normal viewing distance, the human eye can’t detect pixelation. Less pixelation means, crisper, cleaner, more beautiful-looking websites. Newer iPhone and iPad models already use Retina displays, and with the release of the new MacBook Pro, these devices are gaining market share.

That’s great. But for web designers, Retina displays pose a few problems. Plenty of consumers have scrambled for the new MacBook Pro (despite the hefty price tag)—but plenty haven’t. When Retina-display users view a site designed for an ordinary low-res screen, all that pricey pixel potential just gets wasted. But completely revamping web graphics and typography in Retina quality means larger image sizes and longer page-loading times—even for users without Retina display. It’s a lose-lose.

So how’s a designer to create a great cross-platform web experience and stay cutting-edge? The answer is responsive web design (RWD). Just as media queries can be applied to CSS to tell a site how to behave on different devices, they can also be used to change what users see depending on whether they’re viewing in a high-res or low-res environment. It means non-blurry, fast-loading pages for everybody—and less headache for developers.

Dealing with a new set of compatibility standards isn’t always easy. But at Atomic, we’ve made RWD part of our standard development processes, so we can respond and adapt with ease. As it happens, so-called retina-quality devices don’t even come close to the pixel-perceiving quality of the actual human eye (they’re based on 20/20 vision—but plenty of people can see even better).

Retina 2.0 may not be far off—and we’ll be ready.

Do you know how your site looks in Retina-vision? Contact Atomic and we’ll get your page up to snuff.