Hi all! In order to strengthen our link architecture, our editing team will now be adding relevant interlinks to articles that come through our editing queues. These interlinks will preferably be added as hyperlinks in the body of the text but may be added as a "recommended reading" section if there is no easy way to interlink within the text. This strategy does not currently extend to every new article that comes through our curation queues, but that may change down the line.
Improving the internal linking on our sites will help them get indexed by search engines. If you already have strong interlinks in your articles, keep doing what you're doing!
If we are already linking within our articles will the editors leave it alone? (Please)
Thank you for this. My question is will it be site-wide or niche site to niche site linking only?
So, for instance, can I interlink my articles on Dengarden with any on Discover, (or even on Hubpages)?
I suspect it will continue to be niche site to niche site linking only, but let's hope for some more details.
Our editors will prioritize linking to articles on the same niche site, but if articles on other niche sites are highly relevant, those may be linked as well. For example, in an article on PetHelpful about how to train a dog to use a dog door, we might link to an article on DenGarden about how to install a dog door.
Links from our niche sites to Discover or HubPages are not permitted.
I believe this is the right step forward. It will be interesting to see how it affects overall traffic numbers. I sincerely hope more positives are coming our way.
You tell em Glenn, after all you own stock in the Arena Group, and we wouldn't want it to fail would we?
I've been asked in the past to remove them, especially on article that were added to niche sites.
I agree, that was my first thought as well (unless I'm totally misunderstanding). Will this be like what happened a few years ago with our header photo--a number of mine were edited by the HP staff to include text (and gosh, they were ugly). I redid those, finding what I thought were more suitable images, and then began to add that style to the rest of my articles. A few months ago we were told to remove those and have a cleaner appearance with no text on the images. (I have over 400 articles in one niche).
Will we be linked to other writer's articles as well or just our own?
I think the first. In my article about raising a bottlefed lamb I used the word cow milk and the word cow was linked to someone elses article about cows. Same in my article about cats. I mentioned a special color and the word was linked to a completely different article about cats. The latter was in my intro and I didn't like that readers were send away from my article in the first few sentences, so I deleted that sentence.
I believe you are referencing a different link method they implemented a few months back.
The linking to the word cow for example happens on multiple different articles for the first mention of the word and all those links go to the exact same article about cow names. The cow name article even has a link to itself.
It's an automatic system and appears when the word/phrase matches one in the automated system. It is not something that is done by staff.
If you referenced that same color farther down in your cat article, you'll likely see a link there since you removed the word in your intro.
I've checked several articles and it appears that other people's articles can appear in the related article list at the bottom of our articles (and vise versa). I notice on some Dengarden articles, instead of a list after the comments, the related articles appear as a grid after the "Recommended for you" ads.
It would be nice of the interlinks could appear before the glut of ads. Who will really take the time to scroll past those to the content?
Is there a reason why the inline links split up capsules just like ads? Is there no way of controlling placement?
Oh dear, that looks awful. Yet another reason not to stay on a niche site for the average reader! Unbelievable.
HP desperately need a Capsule Continuity Manager, someone who can code for a decent uninterrupted common sense read through of an article.
The code that places the links must be the same as that for ads. So basically it just looks for any HTML closing "p" tag and inserts at that location. I still don't understand why that can't be changed. Surely the editor can be changed so that it inserts dummy tags after modules and the ends of them can be identified? E.g. an "id" tag like what we used to have and allowed us to ad links to sections of a file for the purpose of creating a table of contents.
Those "id" tags on <DIV> statements were no longer present in the HTML when rendered on Maven. And The Arena Group is no better. That’s why our linked TOCs stopped working and had to be removed. So the only way the ad placement can work is between <p> tags, as you mentioned.
If only they would put back those capsule identifiers we used to have under HubPages, they could use that for the ad placement code. But that takes extra programming that they don't seem to have the desire to do. Look how long it's taking to implement the GA4 code that Google keeps warning us about. It took me just five minutes to do that on my site.
It's unfortunate that the ads appear so often, especially at the beginning before we had a chance to convince readers to continue. That might be why our traffic had dropped to 1/3 of what it used to be before The Arena Group took over.
Do you think there's any flexibility as regards the tags/other identifiers ads use to know where to position themselves? Maybe they can only position themselves at the end of paragraphs and there's no means of changing that.
As regards technical people to do the work, it seems Hubpages are out on their own. If TAG was really interested in progress, they'd invest money in hiring people to do the coding or outsource it.
I don't see any flexibility Eugene. I looked at the code. Since Maven/TAG eliminated the <DIV id="mod_xxxxxxx"> there is no other identifier that signifies individiual capsules. The ad placement goes by the <P> tags so ads can appear between any paragraph.
I tried using soft returns (which are two <BR/>) in my first few paragraphs in an effort to capture readers' interest before chasing them away with so many ads, but one editor keeps changing those back to hard returns because the double <BR> looks a little more spacy than regular paragraph spaces in the hubtool.
However, the space is the same when rendered on TAG, so I know he was looking at it in the hubtool. Oh well. I never made it an issue though, because I know the editors are trying their best to help us.
I think the internal link must only led to another HubPages site, other than hubpages and discover. This makes sense if readers are not diverted away from the network sites.
Copyright © 2025 The Arena Media Brands, LLC and respective content providers on this website. HubPages® is a registered trademark of The Arena Platform, Inc. Other product and company names shown may be trademarks of their respective owners. The Arena Media Brands, LLC and respective content providers to this website may receive compensation for some links to products and services on this website.
Copyright © 2025 Maven Media Brands, LLC and respective owners.
As a user in the EEA, your approval is needed on a few things. To provide a better website experience, hubpages.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.
For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: https://corp.maven.io/privacy-policy
Show DetailsNecessary | |
---|---|
HubPages Device ID | This is used to identify particular browsers or devices when the access the service, and is used for security reasons. |
Login | This is necessary to sign in to the HubPages Service. |
Google Recaptcha | This is used to prevent bots and spam. (Privacy Policy) |
Akismet | This is used to detect comment spam. (Privacy Policy) |
HubPages Google Analytics | This is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy) |
HubPages Traffic Pixel | This is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized. |
Amazon Web Services | This is a cloud services platform that we used to host our service. (Privacy Policy) |
Cloudflare | This is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy) |
Google Hosted Libraries | Javascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy) |
Features | |
---|---|
Google Custom Search | This is feature allows you to search the site. (Privacy Policy) |
Google Maps | Some articles have Google Maps embedded in them. (Privacy Policy) |
Google Charts | This is used to display charts and graphs on articles and the author center. (Privacy Policy) |
Google AdSense Host API | This service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy) |
Google YouTube | Some articles have YouTube videos embedded in them. (Privacy Policy) |
Vimeo | Some articles have Vimeo videos embedded in them. (Privacy Policy) |
Paypal | This is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy) |
Facebook Login | You can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy) |
Maven | This supports the Maven widget and search functionality. (Privacy Policy) |
Marketing | |
---|---|
Google AdSense | This is an ad network. (Privacy Policy) |
Google DoubleClick | Google provides ad serving technology and runs an ad network. (Privacy Policy) |
Index Exchange | This is an ad network. (Privacy Policy) |
Sovrn | This is an ad network. (Privacy Policy) |
Facebook Ads | This is an ad network. (Privacy Policy) |
Amazon Unified Ad Marketplace | This is an ad network. (Privacy Policy) |
AppNexus | This is an ad network. (Privacy Policy) |
Openx | This is an ad network. (Privacy Policy) |
Rubicon Project | This is an ad network. (Privacy Policy) |
TripleLift | This is an ad network. (Privacy Policy) |
Say Media | We partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy) |
Remarketing Pixels | We may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites. |
Conversion Tracking Pixels | We may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service. |
Statistics | |
---|---|
Author Google Analytics | This is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy) |
Comscore | ComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy) |
Amazon Tracking Pixel | Some articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy) |
Clicksco | This is a data management platform studying reader behavior (Privacy Policy) |