Monday, February 20, 2017

Strategic SEO Decisions to Make Before Website Design and Build

Posted by Maryna_Samokhina

The aim: This post highlights SEO areas that need to be addressed and decided on before the website brief is sent to designers and developers.

Imagine a scenario: a client asks what they should do to improve their organic rankings. After a diligent tech audit, market analysis, and a conversion funnel review, you have to deliver some tough recommendations:

“You have to redesign your site architecture,” or

“You have to migrate your site altogether,” or even

“You have to rethink your business model, because currently you are not providing any significant value.”

This can happen when SEO is only seriously considered after the site and business are up and running. As a marketing grad, I can tell you that SEO has not been on my syllabus amongst other classic components of the marketing mix. It’s not hard to imagine even mentored and supported businesses overlooking this area.

This post aims to highlight areas that need to be addressed along with your SWOT analysis and pricing models — the areas before you design and build your digital ‘place’:

  • Wider strategic areas
  • Technical areas to be discussed with developers.
  • Design areas to be discussed with designers.

Note: This post is not meant to be a pre-launch checklist (hence areas like robots.txt, analytics, social, & title tags are completely omitted), but rather a list of SEO-affecting areas that will be hard to change after the website is built.

Wider strategic questions that should be answered:

1. How do we communicate our mission statement online?

After you identify your classic marketing ‘value proposition,’ next comes working out how you communicate it online.

Are terms describing the customer problem/your solution being searched for? Your value proposition might not have many searches; in this case, you need to create a brand association with the problem-solving for specific customer needs. (Other ways of getting traffic are discussed in: “How to Do SEO for Sites and Products with No Search Demand”).

How competitive are these terms? You may find that space is too competitive and you will need to look into alternative or long-tail variations of your offering.

2. Do we understand our customer segments?

These are the questions that are a starting point in your research:

  • How large is our market? Is the potential audience growing or shrinking? (A tool to assist you: Google Trends.)
  • What are our key personas — their demographics, motivations, roles, and needs? (If you are short on time, Craig Bradford’s Persona Research in Under 5 Minutes shows how to draw insights using Twitter.)
  • How do they behave online and offline? What are their touch points beyond the site? (A detailed post on Content and the Marketing Funnel.)

This understanding will allow you to build your site architecture around the stages your customers need to go through before completing their goal. Rand offers a useful framework for how to build killer content by mapping keywords. Ideally, this process should be performed in advance of the site build, to guide which pages you should have to target specific intents and keywords that signify them.

3. Who are our digital competitors?

Knowing who you are competing against in the digital space should inform decisions like site architecture, user experience, and outreach. First, you want to identify who fall under three main types of competitors:

  • You search competitors: those who rank for the product/service you offer. They will compete for the same keywords as those you are targeting, but may cater to a completely different intent.
  • Your business competitors: those that are currently solving the customer problem you aim to solve.
  • Cross-industry competitors: those that solve your customer problem indirectly.

After you come up with the list of competitors, analyze where each stands and how much operational resource it will take to get where they are:

  • What are our competitors’ size and performance?
  • How do they differentiate themselves?
  • How strong is their brand?
  • What does their link profile look like?
  • Are they doing anything different/interesting with their site architecture?

Tools to assist you: Open Site Explorer, Majestic SEO, and Ahrefs for competitor link analysis, and SEM rush for identifying who is ranking for your targeted keywords.

Technical areas to consider in order to avoid future migration/rebuild

1. HTTP or HTTPS

Decide on whether you want to use HTTPS or HTTP. In most instances, the answer will be the former, considering that this is also one of the ranking factors by Google. The rule of thumb is that if you ever plan on accepting payments on your site, you need HTTPS on those pages at a minimum.

2. Decide on a canonical version of your URLs

Duplicate content issues may arise when Google can access the same piece of content via multiple URLs. Without one clear version, pages will compete with one another unnecessarily.

In developer’s eyes, a page is unique if it has a unique ID in the website’s database, while for search engines the URL is a unique identifier. A developer should be reminded that each piece of content should be accessed via only one URL.

3. Site speed

Developers are under pressure to deliver code on time and might neglect areas affecting page speed. Communicate the importance of page speed from the start and put in some time in the brief to optimize the site’s performance (A three-part Site Speed for Dummies Guide explains why we should care about this area.)

4. Languages and locations

If you are planning on targeting users from different countries, you need to decide whether your site would be multi-lingual, multi-regional, or both. Localized keyword research, hreflang considerations, and duplicate content are all issues better addressed before the site build.

Using separate country-level domains gives an advantage of being able to target a country or language more closely. This approach is, however, reliant upon you having the resources to build and maintain infrastructure, write unique content, and promote each domain.

If you plan to go down the route of multiple language/country combinations on a single site, typically the best approach is subfolders (e.g. example.com/uk, example.com/de). Subfolders can run from one platform/CMS, which means that development setup/maintenance is significantly lower.

5. Ease of editing and flexibility in a platform

Google tends to update their recommendations and requirements all the time. Your platform needs to be flexible enough to make quick changes at scale on your site.

Design areas to consider in order to avoid future redesign

1. Architecture and internal linking

An effective information architecture is critical if you want search engines to be able to find your content and serve it to users. If crawlers cannot access the content, they cannot rank it well. From a human point of view, information architecture is important so that users can easily find what they are looking for.

Where possible, you should look to create a flat site structure that will keep pages no deeper than 4 clicks from the homepage. That allows search engines and users to find content in as few clicks as possible.

Use keyword and competitor research to guide which pages you should have. However, the way pages should be grouped and connected should be user-focused. See how users map out relationships between your content using a card sorting technique — you don’t have to have website mockup or even products in order to do that. (This guide discusses in detail how to Improve Your Information Architecture With Card Sorting.)

2. Content-first design

Consider what types of content you will host. Will it be large guides/whitepapers, or a video library? Your content strategy needs to be mapped out at this point to understand what formats you will use and hence what kind of functionality this will require. Knowing what content type you will producing will help with designing page types and create a more consistent user interface.

3. Machine readability (Flash, JS, iFrame) and structured data

Your web pages might use a variety of technologies such as Javascript, Flash, and Ajax that can be hard for crawlers to understand. Although they may be necessary to provide a better user experience, you need to be aware of the issues these technologies can cause. In order to improve your site’s machine readability, mark up your pages with structured data as described in more detail in the post: “How to Audit a Site for Structured Data Opportunities”.

4. Responsive design

As we see more variation in devices and their requirements, along with shifting behavior patterns of mobile device use, ‘mobile’ is becoming less of a separate channel and instead is becoming an underlying technology for accessing the web. Therefore, the long-term goal should be to create a seamless and consistent user experience across all devices. In the interest of this goal, responsive design and dynamic serving methods can assist with creating device-specific experiences.

Closing thoughts

As a business owner/someone responsible for launching a site, you have a lot on your plate. It is probably not the best use of your time to go down the rabbit hole, reading about how to implement structured data and whether JSON-LD is better than Microdata. This post gives you important areas that you should keep in mind and address with those you are delegating them to — even if the scope of such delegation is doing research for you (“Give me pros and cons of HTTPS for my business” ) rather than complete implementation/handling.

I invite my fellow marketers to add other areas/issues you feel should be addressed at the initial planning stages in the comments below!


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!



from The Moz Blog http://tracking.feedpress.it/link/9375/5361106
via IFTTT

No comments:

Post a Comment