Mobile Friendly Study

mobile-friendly-teaser

 

In 2015 the Mobile Friendly update of Google is likely the most important change in the algorithms for the year, bringing about a big shift in the SEO industry. Since May 2015 more people have begun to search on mobile devices than at the desktop.

Websites have to adapt to the new rules or the rankings will suffer, in the future most likely with desktop search as well. But what is the right way? Which errors can be made? This study will help inform you about typical errors and how to make the correct  decisions. May the mobile force be with you!

Download and Updates

You can download the complete first part here. This blog post only shows sections of the study. To get the second part of the study (including recommendations , procedures and checklists) please submit the form to get updates on the study. The second part will be published at the end beginning of 2016.

Preface

At the recent Pubcon convention, there where numerous sessions about mobile design and impact, responsive design and the effects on the Google results. Everywhere you can hear that responsive design is the way to go. And we believed so as well. In the past, there were occasional comments that responsive might not be the best solution in some cases. After we gathered all of the data and studied the results, we understood, why some companies do not prefer responsive design. The decision for choosing the right technology isn’t easy.

To our surprise, responsive design in China is much less important. Google doesn’t drive the rules there, but nearly 100% of the adult population in China has a smartphone. In China, numerous companies use apps or still have no mobile optimized pages. Automated technologies exist to convert any website into an app.

Next, we recognized a great deal more problems and errors than we expected. The problems are different depending on the technology, but not one of the studied websites could be categorized as mostly error-free.

So there is still a long way to go and we have decided to create various recommendations and checklists that will be published in Part 2. In addition, we will update that study regularly every sixth months. Even during the creation of our study, things changed, indicating that mobile and responsive technology is developing at a tremendous speed and we cannot forecast the updates in which Google will engage.

This study is not an investigation of the correlations between techniques and rankings in search engines. The relationships between “mobile-friendly” and the search results are still minor but documented. The question is this: what relationships are expected and which new demands will the search engines and their algorithms bring? And which demands do users have regarding mobile user experience?At this time the requirements and criteria of the search engines have just begun.

Why this study?

For several years Google has been driving the technological development of websites with its rules. Since the use of SSL encryption or “mobile-friendly” was proclaimed as a ranking factor, web agencies and service providers for search engine optimization, SEO for short, have been busy trying to make websites for mobile devices acceptable.

As SEO consultants, we have to contend daily with new “mobile-friendly” problems, but this is only the beginning of the mobile era. There is an abundance of solutions on the market, many are different, but often they don’t even meet the minimum requirements of the search engines, let alone are they free of errors. Companies are clearly disoriented and overwhelmed, on the one hand regarding the decision of certain technologies, on the other the acceptance and assessment of monitoring costs. This study will help to make this new market more tangible.
The study should determine the current state of technology and the expected development. The methods used should be examined for their implementations, which typical mistakes are made and whether the procedures used and their errors impact the rankings in search engines. The results of concrete recommendations derived are designed to help website operators in the choice of technology, optimizing and auditing.

Mobile-Friendly: Possibilities of Implementations

Under mobile-friendly, responsive design is especially understood as one’s preferred methodology regarding the preference of Google. It is paramount to allow the user an optimal experience across all channels and devices. But even responsive design has a lot of detailed pitfalls. Nevertheless, Google has created a new path for the first time in this specific realm: Users can get different results with the same searches, depending on which device you are using.

Visibility in the search engines is an important success factor for most companies. Increasingly, the optimum usability of sites plays an important role and also affects the rankings in the search engines. The share of mobile devices regarding the use of the internet continues to grow and increase the challenges.

The launch of the new DM shop system (dm.de) in Germany, which isn’t mobile-friendly or customized for Smartphones, shows that the theme “mobile-friendly” is difficult and a challenge even for large companies, and at the very least it is associated with high costs and the benefits are nebulous.

In order to make websites adaptable to various devices, there are three methods that Google describes in detail:

1)    Responsive Design: Responsive Design: Source code for each page with dynamic adaptation to the screen size and resolution. The adjustment is done via CSS directives in order to adapt the content depending on the resolution.

2)    Alternative URLs: For each page there are one or more different versions that are adapted to different devices. The devices will be redirected to the alternative variants. This should be made clear to the search engines with the use of “alternate media links” in the source code.

3)    Dynamic Allocation of the source code for different devices or device classes. The server returns different source code depending on the device. For search engines, this technology is the most difficult to implement because there can be many different variants for one page.

Google recommends very clearly the use of responsive design. This is understandable for several reasons. Web designers as well as Google must develop or analyze only one page for each website. Still, responsive design doesn’t dominate the market as intended. Many large companies opt for a different solution, and reasons exist for this action. This study is mainly concerned with the implementation and the mistakes that are made and how to fix these. In addition, this study will help you decide which methodology you want to use. Options for the consideration of implementing, auditing and optimizing are also presented.

Databasis

For this study, we analyzed the global Top 500 websites according to Alexa (http://www.alexa.com/topsites), 58 domains of which were not considered for analysis. The reason is that the domains exist only as redirects (ad server) or pages that are not listed in search engines (porn sites, P2P and torrent sites). For these sites, the rules of the search engines do not matter, therefore it makes no sense to take these into account.

Mobile versions for Smartphones are considered especially crucial. Tablets can almost completely represent websites today, therefore, special variants are unusual for tablets and were not statistically evaluated. Nevertheless, the typical problems that exist for tablets will be mentioned and examples included.

Main Results

shares-mobile-technology-enThe chart on the right shows the distribution of the methods used. It has not been considered whether the method was implemented correctly, only how Smartphone customizations take place regarding the device.

The darker colors symbolize the percentage of sites that also offer an app.

Since the first analysis in May, the results have changed significantly. The proportion of sites which are not mobile-friendly, i.e. sites which don’t use one of the three methods mentioned, have continued to fall. The survey of detailed evaluations was carried out from mid-June to mid-September 2015.

Websites that only offer an App as a mobile adaption have been classified as non-mobile-friendly, for example:Flipkart.com.

The following are the main findings, which are illuminated further in the study:

  1. Mobile-Friendly has arrived for website users. Nevertheless, a small portion of websites have made no adjustments for mobile devices, and responsive design as of yet doesn’t dominate the market.
  2. There are no error-free websites. Mistakes are the least among responsive websites, but there is still a great deal of action needed. The market is still in its infancy and the details show numerous problems and weaknesses.
  3.  The Mobile-Friendly test regarding Google as well as the other tests says relatively little about the quality of implementation. For a proper assessment and comprehensive review, extensive tests are necessary. For inspections or audits of mobile websites, this test is not sufficient.
  4. Mobile-Friendly doesn’t necessarily bring (many) more conversions, contacts or sales for all of these websites. Calculating the effort and the expected costs are difficult to assess and highly dependent on the type of website. However, the impact on the rankings will continue to increase.
  5. Standardized mobile solutions such as mobile stores that list only products without additional functionality such as the desktop version should only be a temporary solution. Such standardized solutions are useful for suppliers with only one or very few products.
  6. Cloaking has increasingly become a problem due to the new methods regarding mobile-friendly. How the search engines and website operators handle this issue remains to be seen. Even Google itself is affected by the problem. For search engines, it is once again more difficult to clearly detect cloaking.
  7. Google will further refine its technologies and analyze, evaluate and index mobile versions of a website. Errors in the implementation will have a greater impact in the future, regardless of how useful a mobile version of a website may be. Even websites for which mobile-friendly doesn’t matter will have to submit to the conditions if good positions in the search engines are important for a website in the future.
  8. The automatic detection of non-visible content, intervals and overlapping of elements is technically solved and increasingly integrated into the assessment of the search engines.
  9. The duplicate content problems will increase when implemented alternative URLs or dynamic adjustment and the rules of Google fail to comply. Since Google is testing a mobile index, problems are to be expected for many websites.
  10. Responsive design per se is not an optimal solution for accessibility; rather, it also creates new problems. The study finds that difficultly regarding readability for people with disabilities increases even more.

Examples of the Technologies Used

In studies it has been shown that responsive design can be a good comprehensive solution for all devices. However, responsive design is conceptually limited. The basic structure of a website can thus not fully adjust itself for a particular device or a specific resolution. As a rule, items are hidden, shifted and scaled to match the display device.

But a few examples of implementations also show that a customized solution for specific devices and resolutions specifically allow another method of usability which would be difficult to implement with responsive design.

For example, reddit.com has a fully responsive website but also alternative mobile pages. If you call up the website, the alternative variants will be offered up as rows (left image below). By clicking on it, you will reach the mobile version (right image below).

reddit

The responsive website of reddit.com indicates significant errors at low screen resolutions. The search for the top right corner and the navigation are useless. However, these issues can be resolved. The example shows that Reddit is experimenting with the mobile variant of the beta version (“beta” is shown in the top left in the picture). Regardless, the website could be better adapted to smaller screen resolutions.

Other examples show that many opportunities remain unexploited. Ask.com is responsive only for very limited dimensions. At 780 pixels, the content at the right will already be heavily truncated. The ads from Amazon as well as the questions and answers to the right are unusable or force the user to scroll. A better responsive design for Ask.com can be created with relatively little effort, which is quite simple and feasible. The ads to the right will have no effect in such a case.

ask-780px

 

You have to search for Error-free Websites

The smallest mistakes were implemented with the responsive website, which is also because of the fact that there is only one source code per page. The errors here are therefore generally in the technical implementation regarding the Media Queries. To produce smooth transitions for all elements of a website, you must ensure that no errors occur at any screen resolution.

A typical example of incorrect implementation is Kickstarter.com. The figure below shows screenshots of the website with reduced width. It can be seen in steps 2 and 3 that the search box is superimposed on the elements on the right. In step 4, two menu items break, thereby generating an erroneous representation. Only with a further reduction in resolution is a flawless presentation shown; however, it hides the entire search element.

kickstarter-responsive-problem

The problem is more strongly visible on the German site. The reason is that the text “Sign Up” and “Log in” are longer in German. This problem occurs throughout the study. Generated CSS files and the media queries are often written for a basic language, in many cases English, and then used for other languages. The different lengths of the texts, however, can run counter to the defined media queries.

kickstarter-responsive-problem-DE

The placement in which the two right elements of the navigation appear to the right of the main image is considerably longer in the German version than in English (orange arrow). There are such problems, more or less pronounced, in many responsive sites.

One can illustrate the problem as follows: The figure below shows the navigation in 4 different languages at the same screen width. The top version in English is the only one represented correctly. The other languages are truncated (Spanish: “Buscar proyectos”, French “Recherche des projects” and German “Projekte suchen”).

kickstarter-navigation-languages-zoom

This problem has been known by programmers who have developed applications for decades. The translation of software frequently entails the problem that defined elements of the translated text are not large enough.

The last picture above shows the same problem when zooming. It follows a similar image when the user increases the font. Not all sites offer this directly, but through the operating system and the browser, this option is always possible. This is an important option not only for users with visual impairments but also for users who want to protect their eyes or use a small monitor (referring to pages which are responsive, but not properly adapted to the screen size and pixel density, such as “viewport”, creating a more pronounced problem because users are more prone to zoom for an element such as that). The accessibility of websites is provided here in a new example.

The launch of the shop for the German market leader of drugstore items, dm (www.dm.de), which uses no adaptation for mobile devices, also shows that even large companies avoid this expense for a launch. The future will show how companies react. One can assume that responsive design will dominate web developing in the long term.

A detailed analysis of the most common problems and errors in responsive design is available in Part 2 of the study.

amazon-mobile-tv-slider-problemThe image to the right shows a typical usability problem on a mobile page. At Amazon.com pictures of a product are presented as a slider. The dots symbolize the available pictures (marked with red arrows). But desktop users are used to clicking on those dots or on an arrow to the left or right of the image. In the case of Amazon, there are no arrows to the left or right and the dots are not clickable. Additionally, they are too small to be touched by finger. Only swiping to the right with the finger will present the next image. This phenomenon presents a lack of “desktop user experience adjustment”, in short DUXA. This is an occurrence we often found in different variations on numerous websites.

What does Mobile-Friendly bring?

For this you have to distinguish two things: What does it bring to the user and ultimately the company with respect to more conversions? And what does it bring in terms of the rankings in search engines (primarily based on Google)?

The second question can at least be answered now, which is that the rankings in the search results on mobile devices are becoming more difficult to achieve. Therefore, a website without a mobile-friendly version loses visitors. It is expected that this will continue to increase. Studies show that Mobile in many search operations plays a role, even if the user changes the device. The influences on the ranking with respect to mobile-friendly are therefore likely to have implications on desktops, at least in searches where the location of the searcherdoes not greatly affect the search results.

The present figures regarding modifications of websites to mobile-friendly using different methods show a mixed picture. Basically, an increase in the conversion rate can be observed, although as a rule less than hoped for. Future updates to this study will include additional collected figures.

Technology-driven or User-driven?

For years there has been information about mobile-friendly and responsive design. Google has pushed this issue in its announcements. Here, one has to ask the question as to whether or not web developers adapt pages in order to provide visitors with better usability or primarily to risk no slipping in the rankings, or if both reasons weigh equally. In principle, an assessment is difficult.

shares-mobile-technology-china-enTo this end, Chinese sites were considered in detail in the Alexa 500 list. 24 websites consist purely of Chinese pages or they were created and maintained in China. In China, Google is insignifcant because Google withdrew from China in 2010. Only in Hong Kong is Google available. The market leader Baidu defines the rules.

The distribution of the methods used is completely different. The dynamic adaptation of the source code isn’t used for any sites, and 63% of all websites offer no representation adapted for mobile devices. The percentage of sites that offer an app is 71% (image symbolized by darker colors). Apps dominate the market there.

Baidu is struggling with problems similar to Google. For a longer time, Baidu has communicated the problems concerning mobile devices. The market is different in China because about 90% of the population has a Smartphone, more than 1.2 billion people. In addition, apps are more widespread there, which prompted Baidu to offer the free software SiteApp (http://siteapp.baidu.com) that can create any site from an app.

In early 2014 Baidu set up mobile-friendly rules that are technically unlike Google. There is even a free API that helps site operators to identify and dynamically adapt website devices. The Baidu crawler detects the API usage automatically. Baidu recommends 3 other variants in addition to responsive methods:

1)    Use the Baidu API.
2)    Meta tags (example: <meta name=”mobile-agent” content=”format=html5; url=http://mysite.com/corresponding-mobile-page”>).
3)    Sitemap, in which the mobile versions are listed

Interestingly, these variants, apart from responsive, are different from those of Google. However, they are generally no better or worse. The Meta tag variant is similar to that of Google, but the Meta tag has a different structure. Both versions, however, are in conformity with HTML5. In addition, Baidu does not explicitly require that all mobile versions should use a canonical link element to the desktop version, but this is generally advisable to avoid duplicate content. The API of Baidu allows dynamic adjustment of the source code but does not use the tested pages.

At the end of 2014, Baidu announced the new algorithm “Ice Bucket 2.0″, which punishes problems in mobile display. In the announcement, Baidu regrets that website operators have little consideration for Baidu’s algorithms.

taobao-appThe study shows that considerably more sites in China offer an app (71% of the tested chinese sites). There is no Chinese website that makes the use of such an app mandatory, such as Flipkart.com. However, Baidu complains explicitly over full-page requests and the use of banners that are placed all over the screen about downloading the app.

For example, pictured right is the mobile website Taobao.com, which offers its own app on the website version with full screen resolution. Although Baidu purports rules similar to Google, the market in China is different. Up to now, only influences on the rankings in the search results with Baidu have been announced.

On September 2, 2015 Google announced an update of its own mobile-friendly tests, stating that the large banners by competing website owners that advertise apps are now classified as non-mobile-friendly. Google has caught up to Baidu. It remains to be seen whether web operators in Western countries and in China will follow these innovations in the algorithms.

The question has to be whether or not Google is driving the market and applies pressure or if the perspective of the user is the right way to follow. Doubts persist. It is clear that all search engines face a new challenge and the algorithms and search results will have massive consequences.

Users were accustomed to scrolling and zooming on mobile pages. The question remains whether a targeted adjustment therefore actually adds value. The usability is naturally enhanced, but if this always leads to (many) more conversions is questionable. Customized pages also mean a reduction of the visible content and therefore often a reduction in the overall content.

Apps can be integrated in the Google search results (https://goo.gl/JuFs4t), but they have no indexable content. It is conceivable that this will change if website operators start favoring apps as in China rather than on customized websites.

Technical Fundamentals

To better understand the following discussion and the recommendations in Part 2, a few technical foundations are necessary. All software sends a so-called user agent, a short text in the header of each request based on how one can identify the software. Only then can the server react to the
different browsers. Website operators have already been repeatedly faced with the problem of displaying variants of the site for different browsers. A classic example is Google  itself. In the image below you can see the same search results (on the left for Internet Explorer 8, right for Chrome 40). The results are the same, but the design and presentation differ, and thus the source code.

One can now analyze sites like a search engine and crawl all of the pages, although the results may differ. Google crawls in principle with the user agent Googlebot, which incidentally still has versions for mobile, video, news.

However, one shouldn’t present additional content only to a crawler such as the Googlebot. This is called “cloaking”, the attempt to provide search engines with additional content only for the reason of influencing the search results. However, it is not easy to distinguish between a technical problem and manipulation. Nevertheless, cloaking has long been a reason to be penalized.

Google itself supplies other content. In the following picture below, you can see screenshots of the software Forecheck with an analysis of the website Google.com, on the left with the user agent Googlebot, and to the right with the user agent Chrome 40 on Windows 7. One can already see the differences visually; in fact, one obtains different URLs when crawling.

Whether or not this is intentional and falls under the nomenclature cloaking, the reader can be the judge. After all, Google is even searching for an SEO expert for its own websites. This is urgently needed since many typical SEO problems exist on the pages of Google (http://goo.gl/XF7JZr). Google could thus proceed as a role model and adhere to its own specifications. After all, Google has even punished itself five times in the past.

google_cloaking-useragents
Due to mobile-friendly, the source code of the sites in terms of user agents used is being increasingly adjusted. But if the requirements of the search engines are not exactly respected, this duplicate content can be interpreted as actual duplicate content. This danger exists especially in the variant of alternative URLs. Since the search engines thereby also recommend different methods, this is a Herculean task, especially for international companies.

This not only means that it will be more difficult to distinguish whether or not cloaking actually exists. For search engines, it will be more challenging to detect mobile content. In addition to optimal indexing for crawlers, website operators need to also check out the pages for different devices. The study shows that the sources of errors are numerous.

For this reason, responsive design has as its great appeal the fact that the user agent doesn’t matter, just the screen resolution. This simplifies a lot for website owners and search engines. The clear recommendation from Google on the use of responsive design is comprehensible and makes sense.

Certainly the example of Google already shows that purely responsive websites may also deliver different source code for different user agents. Whether this will now be done for better representation or to customize device-specific source code, it can’t be deduced by inspecting the source code.This also explains why Google has introduced rules for mobile-friendly. The alternate links or the Vary header help the crawlers to understand what is actually going on and what the source code is for a certain purpose.

In the worst case, it may be that a website provides different codes for various device classes (desktop, tablets, Smartphones, feature phones) and also provides different source code for different browsers on these devices. Then one must think about which source you deliver to the crawler. Whether this is actually cloaking can only be said when one has compared the many versions of the source code to the crawlers, which is an almost impossible task.

To discover cloaking, the crawler will therefore also visit websites and use a user agent from a standard browser. These differences in the source code alone aren’t likely to be classified as cloaking. But if the content is different, it is critical. The problem is (which also exists in the case of Google) if the crawler receives the same content but other links. In the case of mobile-friendly, Cloaking is therefore something that will become an important issue once again. Because of the risk that you implemented cloaking “by mistake” increases the demands on mobile-friendly, especially when one evaluates the user agent and the source code, this must be heavily weighed.

In the study, cases were discovered where alternate URLs were used but which also evaluate the user agent and make changes to the source code. This was also noted at responsive sites like Google. Thus, the problem cannot be reduced to the specific techniques used.

Nevertheless, the study also shows that you can make mistakes with responsive design – and that responsive design may not be the optimal solution for all websites. The fact that a lot of websites have decided against pure responsive sites has reasons that one can also understand. Therefore, a decision on which technology is best suited for certain needs isn’t easy. If Google gives responsive websites a bonus in the search results, this would be safe to criticize and may be a disadvantage for certain websites, which Google is in a position of power to do but shouldn’t pursue.

An automated testing of source code relating to a different user agent for an entire website is very difficult. In the future, it will be a possibility with Forecheck to compare two analyses and view the differences in all of the individual analyzed elements. At present, a comparison is only possible manually, for example, if two analyses are exported to Excel and the data is then compared to each other. In any case, you should carry out such tests.

At present it is still unclear whether Google has set up a mobile index. But you have to assume that Google is currently working on it. It is quite possible that in addition to the normal index, there is a supplemental index that includes the mobile versions of desktop websites. Such a supplemental index has existed at Google for some time, but for a different purpose. It is therefore important in each case to examine the indexation of mobile variants today.

The display:none and visibility:hidden Problem

display:none is also like visibility:hidden – a CSS statement that hides certain elements. Although they are present in the source code, they aren’t displayed. Many years ago it was quite a well-known method to package content in the source code which wasn’t displayed. Basically, Google has confirmed that content visible to the user only through a certain action is deemed less important. Texts that can be read only by pop-ups have much less importance for Google. Accordion texts (folding boxes) are a typical example. Therefore, one should examine all occurrences of display:none and visibility:hidden.

display-none-problemIt consists principally of suspicion that problems persist for responsive sites. It is common to reduce the amount of information to smaller screen sizes. Elements can easily be hidden with the use of CSS. However, it is obvious here that the Google algorithm “thinks”: If it disappears, it may not be so important.

The phenomenon was encountered for the first time in 2014 in a client project when an error in the mobile version of a website and through the changes in the CSS instructions,an entire menu was completely hidden in smaller screen widths (orange in the picture). However, this was only caught when all of the documents in this menu path suddenly slid down in the search engine rankings.

It was striking that precisely the documents from this menu, all of which were in a subfolder for only this menu, slid down while other pages didn’t. When the mistake was corrected, the placements rebounded.

One should therefore investigate any use of display:none and visibility: hidden. Their use can naturally be scattered around the source code and CSS files. To use all the resources found in a website, for example, you can use the full text search in Forecheck which can also browse all of the source code.

You should always search the entire website and check the occurrences. In tests, it was found that these statements were not always found existing only in the CSS files. For example, there were numerous Twitter occurrences of display:none in the source code found in various pages (image below).

display-none-search-EN
One must also ask how Google is proceeding with the analysis. The provided usability problems on mobile pages in the Google Search Console show that Google can detect too small or closely spaced elements very well (www.google.com/webmasters/tools/). In addition, the recognition of elements that are only visible through user interaction is also possible with the following, automated technologies:

  • Evaluating the visibility:hidden and display:none instructions in all source code
  • OCR analysis of screenshots from pages (text recognition in images, i.e. screenshots of websites)
  • Analysis of the source code for collisions and spaces (see e.g. JQuery Collision)

The OCR analysis is certainly not possible for any indexing, but it can be performed at longer intervals for websites to compare source code in existing texts with the recognized text from an OCR analysis. The automated verification of spacing and collisions of elements is possible as an automated process, but it’s not realizable for every single crawled page.

Chrome Device Mode & Mobile Emulation

The function Device Mode & Mobile Emulation in Chrome gives the same results as when creating screenshots, only there the elements can be studied and the screen size can be adjusted and tested. This free tool is a safe choice for the testing and inspection of sites. Also for the study, this tool was increasingly used. Caution should be exercised because the tool cannot emulate all characteristics of other browsers and other operating systems! A live test in other browsers is therefore also necessary.

chrome-device-emulation

Alternate Media Links checked by Automation

When the methode of alternate media links is used, the following must be tested:

alt-mobile-funktion

Is there an alternate link to the Mobile Version of this page (image ①)? And does this page have a Canonical link which refers back to the desktop version (image ②)? Does the desktop page at the respective device redirect to the correct mobile page (image ③)? Is it the same URL as the indicated alternate link? An automated test was created in Forecheck. The report “Alternate Link Mapping” makes precisely these tests. In the picture below you can see an example of Twitter.com.

alternate-media-link-errors-twitter

Alternate Link Mapping Report in Forecheck:
The image above shows the alternate link mapping report. Forecheck checks the existing alternate links, its canonical URL and other details such as identical titles/languages. A set of rules for every case explains in detail the problems found. The colors indicate problems or correct data. In the last row, the green marked Canonical URL cell indicates that the Canonical Link directs back to the desktop URL. But the titles of both have different content and different languages, so the alternate mobile page does not map to the desktop URL. Both titles of the row are marked in yellow. This check was processed for all websites in the study. Not one site that uses alternate media links was error-free. Also, some websites use alternate mobile links but do not use the technology in general.

Test Viewport and Vary Header

These issues can be solved in all files with the full text search in Forecheck. One can search within all pages with “name=viewport” to determine whether the viewport is defined in all pages.

Similarly, one can use the search function in the http headers for all headers after “Vary: User-Agent”, the required indication if one adapts the source code dynamically (see image below). No sites had this information fully tested in all of the pages. Details are also included regarding this in Part 2 of the study.

http-header-viewport-very

Conclusion

The study has revealed more problems than expected. In addition, one is at the beginning of a process that will continue to develop for a long time. That none of the large sites is free of errors was nevertheless a surprise, even more so when a number of errors occur in detail.

Other problems, however, were obvious and show how hard a mostly error-free implementation is even for large companies. There are a wealth of challenges and many new issues within the framework of this study, which aims to be analyzed in more detail in updates to this study.

You can download the complete first part here. This blog post only shows sections of the study. To get the second part of the study (including recommendations , procedures and checklists) please submit the form to get updates on the study. The second part wil be published at the end of october.

About Thomas Kaiser

Thomas Kaiser, founder and CEO of Forecheck LLC and cyberpromote GmbH, launched his first company at 23. He developed the first MPEG-2 video coder for Windows at the Technical University of Munich. In 1997 he invented “RankIt!!”, the first SEO software program in Germany. He has also written several books and is a sought-after speaker at SEO conferences and events. He loves playing guitar, enjoys his 5 kids and has drunk SEO milk since birth. You can write him at thomas /at/ forecheck.com.
Facebook
Twitter
Google Plus