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
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.
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
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.
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.