\n
Wireframes<\/h2>\n
Wireframes<\/em> are graphical illustrations of the structure and content of a website that are created before the actual programming of the website begins. Typically, key stakeholders review the graphical wireframes to ensure that the requirements and goals of the new website are met through the design. It is also important that any wireframes are also reviewed from an SEO perspective.<\/p>\n It's easier and cheaper to make adjustments to the website during the design process rather than once the programming has started, and if you have to change a lot of programming afterwards, you risk shifting both the budget and the schedule for the entire migration. Therefore, the resources spent on reviewing and adjusting wireframes are well spent.<\/p>\n When reviewing wireframes from an SEO perspective, you need to pay particular attention to the amount of content there is room for on the pages. As a general rule, the amount of content on a page should be larger than the amount of content that competitors at the top of Google have on their corresponding pages. In practice, this means that a template - which is usually used on many different pages - must be able to accommodate a body text with a widely varying length depending on the individual page.<\/p>\n You can map the content of competitors' pages by performing a relevant Google search and manually counting the number of words on the top ranking pages. Alternatively, you can use a browser plugin such as SEOquake<\/a> to automatically count the number of words.<\/p>\n When reviewing website wireframes, it is also important to ensure that the mobile version of the website does not contain less content than the desktop version. It is the mobile version that Google's indexing of the website is based on (so-called mobile-first indexing<\/a>) and therefore the mobile version must not be a reduced version of the desktop version.<\/p>\n While the new website is under development, it's important that search engines don't indexer\u00a0<\/em>the website. This is partly because strangers shouldn't be able to access the site while it's under development and partly because it can have major consequences for both the visibility of the existing site on Google and the visibility of the new site once it's launched. There are four ways to prevent search engines from indexing your website, the first of which is the one we recommend:<\/p>\n Page architecture <\/em>is an expression of the website's menu structure and page structure. If the development of the new website is preceded by a keyword analysis<\/a>The page architecture should be determined based on considerations from the keyword analysis. This ensures that the website is built with relevant pages with relevant content that the target audience is searching for.<\/p>\n For example, suppose your website consists of a number of category pages, sub-category pages and product pages. If you don't know the search habits of your target audience, you'll create all these pages blindly without knowing if there is a demand for them - unless you have user data from your existing website that can tell you something about your audience's intentions and needs.<\/p>\n A concrete example is a webshop selling workwear. Here is a very brief keyword analysis using Google Keyword Planner:<\/p>\n The analysis shows that there is almost 80 times more demand for 'workwear' than 'workwear', making 'workwear' by far the best choice for a category page. The analysis also shows that there is a high demand for safety shoes, work shoes and work shorts, which can therefore benefit from each having their own category page on the website.<\/p>\n Internal links <\/em>are links on your website that link to other pages on the website. These links need to be updated during the migration to make sure they point to the correct pages on the new website. To update the links, you need to have an overview of all the pages on the new website and know their URLs.<\/p>\n \u00a0<\/em>Examples of internal links are:<\/p>\n We recommend that links are written with relative URLs (for example, '\/specials\/seo' instead of hhttps:\/\/inboundcph.dk\/specialer\/seo'). By making links independent of the domain, you can change the domain without having to correct the links afterwards. If you already use relative URLs and don't change the URLs of the pages during the migration, you probably don't need to update the internal links on the website.<\/p>\n Please note whether the URLs on the new website are written with or without a trailing slash (for example, 'inboundcph.dk\/seo\/' versus 'inboundcph.dk\/seo'). Only one of the two versions can be used as the URL (and users must be automatically redirected from the wrong version to the correct version using a 301-redirect<\/em>). If the URL in internal links is incorrect, users are redirected and the time it takes degrades the user experience.<\/p>\n Finally, a word of advice on internal links in body copy: The purpose of internal links is to guide users to other relevant pages and to help search engines understand the website's structure and most important pages. Therefore, it is an SEO advantage to link internally to the most important pages on the website that are also important for you to be visible on Google.<\/p>\n Content is crucial for a website's visibility on Google, so it's important that relevant content from the existing website is at least retained and, if possible, expanded and optimized based on a keyword analysis. Relevant content in this context is defined as content that has received a significant number of visitors from Google over a 12-month period. How high a number of visitors is significant is up to you to consider.<\/p>\n You can use Google Analytics to see which pages have received visitors from Google. Click 'Behavior' in the menu on the left and then 'Site content' and 'All pages'. If you only want to see visitors from Google (so-called organic traffic), you can add a segment at the top of the page - but remember that it's not just the number of visitors from Google that determines whether a page is retained.<\/p>\n It's important that you measure visitor numbers over a period of 12 full months. There may be relevant pages that only get traffic during certain periods - for example, Christmas-related pages - and you will lose that knowledge if you only look at traffic from the last month, for example. If you remove pages with visitor traffic, it goes without saying that you will lose that traffic on the new website.<\/p>\n The number of inbound links (i.e. links from other websites) to the pages on your website should also influence which pages you choose to keep. Inbound links are an essential part of SEO and one of the things Google weighs most heavily when determining positioning<\/a> of a website. Therefore, you should avoid removing pages that have one or more inbound links.<\/p>\n You can view inbound links to your pages using a tool such as Ahrefs.com<\/a> (commercial). However, a better solution is to use Screaming Frog<\/a> (commercial) and via this set up an integration to Google Search Console and Ahrefs.com. This way you have data about both the sites, their visitor traffic from Google and inbound links all in one place.<\/p>\n While some content should be retained during a migration, it is rarely unavoidable that there is also a need to make significant changes to the existing content. These changes can include customizing content, moving content and deleting content. I the post about migration<\/a> we provide more in-depth recommendations for these content changes.<\/p>\n From a technical perspective, there are a number of areas your web developers need to consider when developing a new website. Many of these areas are relevant for all types of new developments - whether you're developing a completely new website or simply moving it from one domain to another - while others are only relevant in some cases. There are many areas, and it can be a lengthy process to get a handle on everything.<\/p>\n Among the areas are for example Redirects (redirects)<\/em>that automatically redirects users from the old to the new website, a XML sitemap<\/em>that helps Google find all the pages on the new website, and a robots.txt file<\/em>, which tells Google which parts of the new website it can index. It is important for redirects that all pages on the old website are mapped in a spreadsheet (for example, using Screaming Frog<\/a>) before the site is taken down. The mapping will be used to later test if the redirects work.<\/p>\n The above areas and many others are described in our SEO book<\/a>. Once again, it is important to point out that this is not a complete checklist for technical SEO, but an overview of areas that are essential for a migration. For example, SEO important areas such as hreflang <\/em>and mobile-friendliness<\/em> not included because they are not directly related to the migration of a website.<\/p>\n Most websites collect statistics about their users through systems such as Google Tag Manager, Google Analytics, Adobe Analytics, Google Search Console, Leadfeeder, Facebook pixel and LinkedIn Insight Tag. These systems need to be set up on the new website so that data is not lost when the website is launched. If data is lost after migration, you also lose the ability to quickly evaluate and assess the impact of the migration.<\/p>\n It is also important that any conversion tracking in Google Analytics is set up on the new website. If you use third-party integrations (such as Zapier) to automatically collect data from the website and integrate this data with other systems, make sure these integrations are set up on the new website before the migration.<\/p>\n Before launching the website, the new website must be tested for technical errors and inconsistencies and these must be fixed before the migration takes place. As a minimum, the test should include the areas in the checklist below.<\/p>\n If you want to ensure that the new website meets all technical SEO requirements, you may want to conduct a more thorough technical analysis of the website based on the technical chapter in our SEO book<\/a>. This extended analysis can touch on areas such as load time, mobile-friendliness, canonical tags, hreflang tags, page titles, response codes and structured data.<\/p>\n Foruds\u00e6tningen for en succesfuld ny hjemmeside er, at det tekniske fundament for hjemmesiden er i orden \u2013 dvs. at der ikke er tekniske fejl og uhensigtsm\u00e6ssigheder, der forringer hjemmesidens kvalitet og forhindrer Google i at indeksere websitet. Det er samtidig en foruds\u00e6tning, at eksisterende indhold fra en eventuel gammel hjemmeside bibeholdes, udvides eller optimeres med […]<\/p>\n","protected":false},"author":1,"featured_media":15193,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[91],"tags":[],"class_list":["post-14088","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknisk-seo-noerderi_cat"],"acf":{"form":false,"post_short_description":"N\u00e5r du udvikler en ny hjemmeside, er der en r\u00e6kke overvejelser, du skal g\u00f8re dig. Disse skal sikre, at hjemmesiden udvikles p\u00e5 en hensigtsm\u00e6ssig m\u00e5de, s\u00e5 du f\u00e5r den maksimale synlighed p\u00e5 Google. L\u00e6s vores anbefalinger til udvikling af en ny hjemmeside her.","post_authors":[13325],"post_contact_section":{"post_contact_section_employee":13364,"post_contact_section_title":"Kom i dialog med os","post_contact_section_text":"Vi forst\u00e5r, at det kan v\u00e6re en stor beslutning at v\u00e6lge et bureau. Men h\u00e5nden p\u00e5 hjertet \u2013 var vi dig, s\u00e5 havde vi valgt os selv. Vores kunder kalder os Danmarks \u00e6rligste og mest n\u00e6rv\u00e6rende bureau \u2013 og hos os finder du specialister, der mestrer strategi og digital marketing. M\u00e5ske er vi ogs\u00e5 det helt rigtige bureau for dig? Kontakt os & find ud af det."}},"yoast_head":"\n
\nIndexing<\/h2>\n
\n
\nPage architecture<\/h2>\n
![\"\"](\"https:\/\/inboundcph.dk\/wp-content\/uploads\/2024\/04\/ny-hjemmeside-2.png\")
<\/p>\n
\nInternal links<\/h2>\n
\n
\nContent requirements<\/h2>\n
\nTechnical requirements<\/h2>\n
\nData collection and data flow<\/h2>\n
\nTesting the website<\/h2>\n
\n