How you structure internal links determines how well your blog integrates with the main site. Your blog will have its own directory, or it will live on a separate sub-domain. Both options are feasible in most cases. Also in most cases, the blog uses a different CMS than the main site. Leading to different menus (top and bottom menus) by default. Is it better for SEO to keep this approach or should you have both sites share the same menu structures? The quick answer is keep the same menu for both sites. If you want to know why, keep reading to explore how I reach that conclusion and how I’ve implemented the approach on my PHP-built website.
Importance of Internal Links for SEO
To understand why links are important for SEO, you must first grasp the concept of the “PageRank” algorithm. It’s used by Google and Bing to rank individual webpages. Documents (pages) are given a “PageRank” score based on the relationships (hyperlinks) between different documents. The more a document receives links, the higher its score. The search engines apply variations of this algorithm but that’s the initial idea behind “PageRank.”
Internal links disseminate “PageRank” throughout your website. Most SEO experts recommend using a hierarchical structure (versus flat structure, in which every page links to each other). Google processes internal links more granularly by ignoring internal links that are the same on every page (such as menu, footer, and non-distinct sidebar links) but exceptions do exist depending on how many pages live on your website. Although Google ignores non-distinct link elements for calculating “PageRank,” they’re still important for the sake of crawling your website.
Combined with other ranking factors, internal links help your page rank for keyword search terms on SERPs (search engine results pages). Hence, how you structure your website impacts your visibility.
Sub-domain vs Folders for SEO
In most CMS softwares, folders are automatically part of the main domain and will usually share the same menu and footer links. This implies a close association with other pages of the main domain. Most content management systems make it easy to interlink between similar folders and pages that are within the same sections. You can still achieve a hierarchical structure with internal links, but search engines will treat all pages in the main section as belonging to that domain. If there are sub-domains, by default they will never appear in sitelinks on SERPs since they technically don’t belong to the same domain and sub-domains will usually have different menu and footer links.
Sub-domains can follow a standalone structure or share the same structure as the main domain. See the diagram below for a visual example.
The blue box is the standard configuration for sub-domains. A small percentage of links on the sub-domain might connect with the main domain, but it’s mostly standalone with its own structure. Different menu and footer links. If you receive external links to the sub-domain, the “PageRank” is mostly contained and there’s little dissemination to the main domain. Even crawling could be limited, depending on how many links exist from the sub-domain. On SERPs, the main domain and the sub-domain can have different sitelinks and none of the sub-domain pages would ever appear under the main domain’s SERP snippet.
The red box happens when sub-domains contain the same menu and footer links as the main domain and there are plentiful internal links between both domains. In this arrangement, the sub-domain is treated as a folder and can appear alongside SERP sitelinks snippet for the main domain. Plus, “PageRank” is disseminated between both domains and crawling activity from search engines is probably more frequent for both sections.
What is Google’s Opinion?
Google provides its own non-direct answer inside their Search Quality Raters Guidelines. Page 13 of the document uses one of Harvard’s sub-domains in an exercise of identifying the homepage. Notice how it tells the rater to inspect the logo link and observe its link destination. A logo link on a sub-domain would be considered a part of Harvard’s main website if it linked to Harvard’s main homepage. However, if the logo link connected to the sub-domain homepage, the rater could interpret the sub-domain as being a separate site with its own distinct homepage. This is a clue that Google analyzes the internal link structure of the main site and sub-domains to determine whether the sub-domain is a part of the entirety of the site or distinct from it.
What are Clues from Google SERPs?
Google’s SERPs may provide another clue that answers whether your site’s internal link structure determines how your sub-domain is treated. Let’s compare one of my websites and Yahoo. My keto food search engine is located at ketofoodist.com and I have a blog for it at blog.ketofoodist.com; both sites share the same menu and footer links. Yahoo has lots of sub-domains; each sub-domain has its own set of menu links.
Here’s a screenshot of Ketofoodist.com when typing its domain name in Google Search. The highlighted sitelinks are sub-domain URLs but they appear as part of the main site.
Here’s a screenshot of Yahoo.com when searching for it in Google Search. You’ll notice that two sub-domains appear: money.yahoo.com and finance.yahoo.com. Each containing distinct sitelinks.
Notice above that I typed in “yahoo money” and the SERP produced Yahoo! Money and Yahoo! Finance sub-domain sitelinks in their respective snippets. Could I produce a similar appearance for “ketofoodist blog” in a SERP? Nope.
In the SERP screenshot, you see a bunch of links for blog.ketofoodist.com along with a link for the main site (ketofoodist.com). There are no sitelinks; the reason is because the blog sub-domain shares much of the same internal links as the main site by using the same menu and footer links. And, the header logo links to the main site homepage on the main site and sub-domain.
So the answer to the question—can your main site and blog have the same menu—is a resounding yes and there are SEO benefits. Sharing the same menu and footer links theoretically allows “PageRank” that flows to your blog sub-domain to disseminate throughout your main site. The next section demonstrates how you can leverage WordPress to be the menu manager for your main site and blog sub-domain. I use the same solution on Ketofoodist.
My Approach to Standardizing Menus – WordPress API Example
The goal is to produce a set of menu and footer links that can be displayed on ketofoodist.com and blog.ketofoodist.com. I’ll demonstrate how I accomplished by leveraging the WordPress API.
Please note: the following process involves familiarity with programming languages. This solution works for my website and I cannot guarantee it’ll work for the reader’s website. If you decide to use the code below, or any code in this article, I bear no responsibility how it impacts your website.
First, I need a way to output menu links and structure to the WordPress API REST endpoint. This doesn’t happen by default. While there are programmatic ways of making this happen, I opted for a plugin. I won’t reveal the exact plugin being used but you can use Google Search or the WordPress plugin directory to discover plugins which export menu data to the API.
Second, I need a function that will restructure the menu data in the API so that I can easily work with it. The WordPress API provides a lot of data; condensing its form makes it more convenient to consume it. Here’s the structure that I desire per menu link:
- “Label”
- “URL”
- “Childs”
- “Label”
- “URL”
- “Childs”
Since I plan to implement sub-menu items, I need a way for the structure to contain those items using the same “Label”/”URL”/”Childs” menu structure. The code below connects to the REST API endpoint using PHP’s curl library and uses an anonymous recursion function to build the menu data structure. It takes the menu slug as an input (using the menu slug provided by WordPress in the menu interface) and returns the menu structure data.
/** Retrieves menus from the WP API by use of the API slug
*
* @param $menu_slug (string) - slug of the menu to use for the API
*
* @return $menu_results (array) - menu data
*/
function wp_menu_api( $menu_slug = "" ) {
//WP API URL
$api_url_1 = "https://your_domain_here.com/wp-rest-api-slug/" . $menu_slug;
$ch = curl_init();
curl_setopt_array( $ch, array(CURLOPT_URL => $api_url_1, CURLOPT_HEADER => 0, CURLOPT_RETURNTRANSFER => 1) );
$wp_feed = curl_exec( $ch );
$json_feed = JSON_decode( $wp_feed );
//revert to backup saved file in home directory
//otherwise, end the function
if ( empty($json_feed) ) {
return false;
}
$items = $json_feed->items;
//recursion function: auto-attaches child items if they're present
$menu_data = function($array) use ( &$menu_data ) {
$return_array = [];
for( $i = 0; $i < count($array); $i++ ) {
$return_array[$i] = array(
"Label" => $array[$i]->post_title,
"URL" => $array[$i]->url
);
if ( isset($array[$i]->child_items) ) {
$return_array[$i] = array_merge( $return_array[$i], array("Childs" =>
$menu_data($array[$i]->child_items)) );
}
}
return $return_array;
};
$menu_results = $menu_data($items);
curl_close( $ch );
return $menu_results;
}The anonymous in-function $menu_data returns the desired data structure. It takes the items node from the WordPress API and inputs it to $menu_data. The “for” loop iterates through each sub-node in items and assigns post_title to “Label” and “URL” to each array element of $return_array. If there are sub-menu items, they’ll be listed under child_items node in the WordPress API (the code uses “isset” to check for sub-menu items); that is inputted to $menu_data and the in-function runs recursively. The results of the recursive function are merged with $return_array using “array_merge”.
How do I display the menu data? For the top menu, here’s the code I use (below). It loops through each menu item (using “foreach”) and detects if sub-menu items are present (using the “isset” function). Special HTML is outputted to handle sub-menu items. Otherwise, the normal list HTML is displayed.
<ul>
<?php foreach( $top_menu as $menu ) : ?>
<li><span><a href="<?php echo $menu['URL']; ?>"><?php echo $menu["Label"]; ?></a></span>
<?php if ( isset($menu["Childs"]) ) : ?>
<ul>
<?php foreach ( $menu["Childs"] as $child ) : ?>
<?php if ( isset($child["Childs"]) ) : ?>
<li><span><a href="<?php echo $child['URL']; ?>"><?php echo $child["Label"]; ?></a></span>
<ul>
<?php foreach ( $child["Childs"] as $nest_child ) : ?> <li><a href="<?php echo $nest_child['URL']; ?>"><?php echo $nest_child["Label"]; ?></a>
</li>
<?php endforeach; ?>
</ul>
</li>
<?php else : ?>
<li><a href="<?php echo $child['URL']; ?>"><?php echo $child["Label"]; ?></a></li>
<?php endif; ?>
<?php endforeach; ?>
</ul>
<?php endif; ?>
</li>
<?php endforeach; ?>
</ul>These codes are used on the main site (ketofoodist.com), which is built utilizing my own custom framework, and used on the WordPress blog, blog.ketofoodist.com (since they both leverage PHP). On WordPress, the API code can be inserted in the “functions.php” file or by a custom plugin that uses an include statement. The menu display code can be inserted in the “header.php” file or whichever file is used to output the header for the blog. I can use WordPress’s menu manager to configure menu links and structures for both ketofoodist.com and blog.ketofoodist.com.