Google’s John Mueller answered a question about why some websites use multiple XML sitemaps instead of a single file. His answer suggests that what looks like unnecessary complexity may come from reasons that are not immediately obvious.
The question came from an SEO trying to understand why managing multiple sitemap files would be preferred over keeping everything in one place.
Question About Using Multiple Sitemaps
The SEO framed the issue as a matter of efficiency, questioning why anyone would choose to increase the number of files they have to manage.
“Can I ask a silly question, what’s the advantage of multiple site maps? It seems like your going from 1 file to manage to X files to manage.
Why the extra work? Why not just have 1 file?”
It’s a good question, avoiding extra work is always a good idea in SEO, especially if someone has a relatively small website, it makes sense to have just one sitemap but as Google’s Mueller explains, there may be good reasons to split a sitemap into multiple files.
Mueller Explains Why Multiple Sitemaps Are Used
Mueller responded by listing several reasons why multiple sitemap files are used, including both practical and less intentional causes.
He responded:
“Some reasons I’ve seen:
want to track different kinds of urls in groups (“product detail page sitemap” vs “product category sitemap” — which you can kinda do with the page indexing report)
split by freshness (evergreen content in a separate sitemap file – theoretically a search engine might not need to check the “old” sitemap as often; I don’t know if this actually happens though)
proactively split (so that you don’t get to 50k and have to urgently figure out how to change your setup)
hreflang sitemaps (can take a ton of space, so the 50k URLs could make the files too large)
my computer did it, I don’t know why”
Mueller’s answer shows that sitemaps can be used in creative ways that serve a purpose. Something I’ve heard from enterprise level SEOs is that they find that keeping a sitemap to well under 50k lines ensures better indexing.
Takeaways
Mueller’s answer shows that sometimes keeping things “simple” isn’t always the best strategy. It might make sense apply organization to the sitemaps appears to be unnecessary complexity is often the result of practical constraints, evolving site structures, or automated systems rather than deliberate optimization.
Multiple sitemaps can be used to group different types of content
They help avoid hitting technical limits like the 50,000 URL cap
Some implementations are based on theory rather than confirmed behavior
Not all sitemap structures are intentional or strategically planned
Featured Image by Shutterstock/Rachchanont Hemmawong
Artificial intelligence led all employer-cited reasons for U.S. job cuts in March, accounting for 15,341 of the month’s 60,620 announced layoffs, according to outplacement firm Challenger, Gray & Christmas.
That’s 25% of all cuts for the month, up from roughly 10% in February.
Since Challenger began tracking AI as a reason in 2023, employers have now cited it in 99,470 layoff announcements, or 3.5% of all cuts during that period.
What The Numbers Show
Total U.S. job cuts rose 25% from February to March but are down 78% from March 2025, when a wave of federal layoffs pushed that month’s total to 275,240.
For the first quarter overall, employers announced 217,362 cuts. That’s the lowest Q1 total since 2022.
AI ranks fifth among all cited reasons year-to-date, behind market and economic conditions, restructuring, closings, and contract loss. But its share is growing. In all of 2025, AI accounted for 5% of cited cuts. Through Q1 2026, it’s at 13%.
These are employer-stated reasons, not independently verified causes. Companies may cite AI when cuts involve broader cost restructuring.
Technology Sector Hit Hardest
Technology companies announced 18,720 cuts in March alone, bringing the 2026 total to 52,050. That’s up 40% from the 37,097 tech cuts announced in the same period last year. It’s the highest year-to-date total for the sector since 2023.
Andy Challenger, the firm’s chief revenue officer, said the pattern goes beyond traditional cost-cutting.
“Companies are shifting budgets toward AI investments at the expense of jobs. The actual replacing of roles can be seen in Technology companies, where AI can replace coding functions. Other industries are testing the limits of this new technology, and while it can’t replace jobs completely, it is costing jobs.”
Dell accounted for a large portion of March’s tech cuts based on its latest annual filing, according to the report. Oracle reportedly began layoffs late last month but has not released a total. Meta is also cutting roles in its Reality Labs division as it redirects resources toward AI.
Other Industries
Transportation companies announced the second-most cuts year-to-date with 32,241, up 703% from the same period in 2025. It’s the highest Q1 total for the sector on record.
Healthcare announced 23,520 cuts in Q1, also a record for the sector.
The news industry, tracked as a subset of media, announced 639 cuts through Q1 2026, up 12% from 573 in the same period last year.
Why This Matters
The Challenger data puts company-level numbers behind what workforce projections have estimated.
SEJ recently covered the Tufts American AI Jobs Risk Index, which ranked computer programmers at 55% vulnerability and web developers at 46%.
Challenger’s report separately shows tech sector cuts at their highest since 2023 and AI as the top employer-cited reason for March layoffs overall. The two datasets measure different things, but they point in the same direction.
For people working in search, content, and digital marketing, Challenger’s data adds another reference point to track alongside academic projections and company earnings calls.
Looking Ahead
Challenger said he expects more tech layoffs in 2026 as companies continue redirecting budgets toward AI.
“One thing that is clear is that AI is changing work and the workforce. Workers will need to be more strategic as they lead AI-powered agents that handle increasingly complex tasks.”
Challenger, Gray & Christmas publishes updated cut data monthly.
Cloudflare announced a new content management system called EmDash that it says is the “spiritual successor to WordPress.” Could EmDash be your next content management system? Here are six reasons why EmDash may be the content management system of tomorrow… but not today.
1. EmDash Is Not User Focused
Cloudflare’s biggest selling point for its new CMS, as stated in the title of the announcement, is that it solves the WordPress security problem. Over 25% of the announcement focuses on discussing plugin security.
The remaining 73% of the announcement is dedicated to:
Background information about the evolution of web development.
Putting WordPress within the context of the history of web development.
The technical architecture.
Security and authentication.
Readiness for the x402 standard, which enables users to monetize agentic website traffic.
There are over 2,700 words in that announcement, and the only part that arguably has direct importance to actual users like bloggers, businesses, and other publishers is the part about plugin security. The rest of the content is developer- and coder-focused and not user-focused at all.
There are many reasons to choose a CMS, and while security is important to businesses and online publishers, there are other reasons that are far more important.
2. The Case For Plugin Security
Cloudflare explains that WordPress plugin security is compromised because plugins are granted full access to a website’s internal files and database. This lack of boundaries means that if a single plugin has a flaw or malicious intent, it can compromise the entire site. The announcement explains that the vast majority of security vulnerabilities (96%) originate from third-party plugins.
What the announcement doesn’t say is that the vast majority of WordPress plugin vulnerabilities are not likely to be exploitable at scale. Only 17% of plugins are high severity, and of those, many of them are not installed on many websites.
“1,966 (17%) vulnerabilities had a high severity score, meaning they were likely to be exploited in automated mass-scale attacks.
…Furthermore, our Zero Day program found 33 highly critical vulnerabilities in Premium components, compared to only 12 in free components.”
There are many WordPress vulnerabilities discovered every day, but most of them are low risk and are found on plugins that are not widely used. If plugin security is EmDash’s main selling point, it’s not much of a selling point in the real world.
Cloudflare’s solution for improving plugin security is solid and well designed. However, a reasonable argument could be made that Cloudflare’s case for plugin security is overstating its importance in the overall scheme of what users actually need.
3. EmDash Is Built To Solve Infrastructure Problems
In a post on X, Jamie Marsland of Automattic acknowledged that EmDash offers innovative solutions but argues that its focus is on solving infrastructure issues and is not focused on the daily problems that an actual CMS user (like a restaurant owner or a recipe blogger) would be interested in.
Marsland makes the point that developers may care about “cleaner abstractions” and “isolate runtimes,” but small business owners care about things like bookings, SEO, and customer acquisition. He uses the analogy of EmDash being a “tidy desk” for people who aren’t actually looking to tidy their desks but rather are focused on using a CMS that helps them run a business.
“…when very smart people rebuild something from scratch, they tend to fix the problems they can see most clearly. And the problems Cloudflare sees are very real:
Plugin security (sandboxing, isolation)
Serverless scaling
Modern developer experience
AI-native programmability
All of which make perfect sense… If you are looking at the world from inside an infrastructure company.
…If you are a developer, this feels like someone has finally tidied your desk. The problem is that most people are not trying to tidy their desk.
They are trying to run a business from it while:
replying to emails
posting on social
updating their website
wondering why traffic dropped”
4. EmDash May Not Be User Friendly
EmDash is built on Astro, which technically is not a CMS; it’s a web framework. EmDash wraps Astro around a graphical user interface (GUI) for content management that may feel familiar to anyone who has used WordPress. But setting it all up is not as easy as WordPress’s famous five minute setup because it can involve connecting to a GitHub repository and configuring database settings. The same is true for getting the site to look how a user wants it to look.
It has a GUI for managing content, but it does not (yet) have a point-and-click website builder the way most modern content management systems like WordPress and Wix do.
5. Command Line Interface
I’m old enough to remember what using a desktop computer in 1980 was like. The interface was essentially a command line interface, with a cursor impatiently blinking at the user, waiting for cryptic commands to make it do something. It was not until 1983 that Apple introduced a graphical user interface (GUI) that made interacting with a computer easy for everyday users.
Image by Shutterstock/AG_Design_stocks
If you like typing cryptic commands to make a computer function, then EmDash’s command line interface is for you. At this point, users won’t be able to get away from it because users currently cannot set up an EmDash site from scratch without resorting to a CLI. Even the “one-click” deployment options in the Cloudflare Dashboard eventually require technical configuration that is usually handled via the terminal.
6. EmDash Is Not Ready For Most Users
I was quite excited to read Cloudflare’s announcement about a “spiritual successor” to WordPress, but the more I read, the more it became apparent that EmDash is not the solution I am looking for. Yes, I want a fast-performing website. Yes, I want a site that is secure and won’t surprise me one day with Japanese text.
But I don’t want to deal with a CLI, and I do want an easy-to-use interface for setting up and building an attractive website for myself. EmDash is not ready for general use. It’s still in early developer beta. The version number on it is 0.1.0, so at this point it’s literally not for the average user.
Hopefully, some day it will be a viable competitor to WordPress, but EmDash is not that right now.
Google’s John Mueller responded to a question about whether core updates roll out in stages or follow a fixed sequence. His answer offers some clarity about how core updates are rolled out and also about what some core updates actually are.
Question About Core Update Timing And Volatility
An SEO asked on Bluesky whether core updates behave like a single rollout that is then refined over time or if the different parts being updated are rolled out at different stages.
The question reflects a common observation that rankings tend to shift in waves during a rollout period, often lasting several weeks. This has led to speculation that updates may be deployed incrementally rather than all at once.
“Given the timing, I want to ask a core update related question. Usually, we see waves of volatility throughout the 2-3 weeks of a rollout. Broadly, are different parts of core updated at different times? Or is it all reset at the beginning then iterated depending on the results?”
Core Updates Can Require Step-By-Step Deployment
Mueller explained that Google does not formally define or announce stages for core updates. He noted that these updates involve broad changes across multiple systems, which can require a step-by-step rollout rather than a single deployment.
He responded:
“We generally don’t announce “stages” of core updates.. Since these are significant, broad changes to our search algorithms and systems, sometimes they have to work step-by-step, rather than all at one time. (It’s also why they can take a while to be fully live.)”
Updates Depend On Systems And Teams Involved
Mueller next added that there is no single mechanism that governs how all core updates are released. Instead, updates reflect the work of different teams and systems, which can vary from one update to another.
He explained:
“I guess in short there’s not a single “core update machine” that’s clicked on (every update has the same flow), but rather we make the changes based on what the teams have been working on, and those systems & components can change from time to time.”
Core Updates May Roll Out Incrementally Rather Than All At Once
Mueller’s explanation suggests that the waves of volatility observed during core updates may correspond to incremental changes across different systems rather than a single reset followed by adjustments. Because updates are tied to multiple components, the rollout may progress in parts as those systems are updated and brought fully live.
This reflects a process where some changes are complex and require a more nuanced step-by-step rollout, rather than being released all at once, which may explain why ranking shifts can appear uneven during the rollout period.
Connection To Google’s Spam Update?
I don’t think that it was a coincidence that the March Core update followed closely after the recent March 2026 Spam Update. The reason I think that is because it’s logical for spam fighting to be a part of the bundle of changes made in a core algorithm update. That’s why Googlers sometimes say that a core update should surface more relevant content and less of the content that’s low quality.
So when Google announces a Spam Update, that stands out because either Google is making a major change to the infrastructure that Google’s core algorithm runs on or the spam update is meant to weed out specific forms of spam prior to rolling out a core algorithm update, to clear the table, so to speak. And that is what appears to have happened with the recent spam and core algorithm updates.
Comparison With Early Google Updates
Way back in the early days, around 25 years ago, Google used to have an update every month, offering a chance to see if new pages are indexed and ranked as well as seeing how existing pages are doing. The initial first days of the update saw widescale fluctuations which we (the members of WebmasterWorld forum) called the Google Dance.
Back then, it felt like updates were just Google adding more pages and re-ranking them. Then around the 2003 Florida update it became apparent that the actual ranking systems were being changed and the fluctuations could go on for months. That was probably the first time the SEO community noticed a different kind of update that was probably closer a core algorithm update.
In my opinion, one way to think of it is that Google’s indexing and ranking algorithms are like software. And then, there’s also hardware and software that are a part of the infrastructure that the indexing and ranking algorithms run on (like the operating system and hardware of your desktop or laptop).
That’s an oversimplification but it’s useful to me for visualizing what a core algorithm update might be. Most, if not all of it, is related to the indexing and ranking part. But I think sometimes there’s infrastructure-type changes going on that improve the indexing and ranking part.
Google’s Gary Illyes published a blog post explaining how Googlebot’s crawling systems work. The post covers byte limits, partial fetching behavior, and how Google’s crawling infrastructure is organized.
The post references episode 105 of the Search Off the Record podcast, where Illyes and Martin Splitt discussed the same topics. Illyes adds more details about crawling architecture and byte-level behavior.
What’s New
Googlebot Is One Client Of A Shared Platform
Illyes describes Googlebot as “just a user of something that resembles a centralized crawling platform.”
Google Shopping, AdSense, and other products all send their crawl requests through the same system under different crawler names. Each client sets its own configuration, including user agent string, robots.txt tokens, and byte limits.
When Googlebot appears in server logs, that’s Google Search. Other clients appear under their own crawler names, which Google lists on its crawler documentation site.
How The 2 MB Limit Works In Practice
Googlebot fetches up to 2 MB for any URL, excluding PDFs. PDFs get a 64 MB limit. Crawlers that don’t specify a limit default to 15 MB.
Illyes adds several details about what happens at the byte level.
He says HTTP request headers count toward the 2 MB limit. When a page exceeds 2 MB, Googlebot doesn’t reject it. The crawler stops at the cutoff and sends the truncated content to Google’s indexing systems and the Web Rendering Service (WRS).
Those systems treat the truncated file as if it were complete. Anything past 2 MB is never fetched, rendered, or indexed.
Every external resource referenced in the HTML, such as CSS and JavaScript files, gets fetched with its own separate byte counter. Those files don’t count toward the parent page’s 2 MB. Media files, fonts, and what Google calls “a few exotic files” are not fetched by WRS.
Rendering After The Fetch
The WRS processes JavaScript and executes client-side code to understand a page’s content and structure. It pulls in JavaScript, CSS, and XHR requests but doesn’t request images or videos.
Illyes also notes that the WRS operates statelessly, clearing local storage and session data between requests. Google’s JavaScript troubleshooting documentation covers implications for JavaScript-dependent sites.
Best Practices For Staying Under The Limit
Google recommends moving heavy CSS and JavaScript to external files, since those get their own byte limits. Meta tags, title tags, link elements, canonicals, and structured data should appear higher in the HTML. On large pages, content placed lower in the document risks falling below the cutoff.
Illyes flags inline base64 images, large blocks of inline CSS or JavaScript, and oversized menus as examples of what could push pages past 2 MB.
The 2 MB limit “is not set in stone and may change over time as the web evolves and HTML pages grow in size.”
The platform description explains why different Google crawlers behave differently in server logs and why the 15 MB default differs from Googlebot’s 2 MB limit. These are separate settings for different clients.
HTTP header details matter for pages near the limit. Google states headers consume part of the 2 MB limit alongside HTML data. Most sites won’t be affected, but pages with large headers and bloated markup might hit the limit sooner.
Looking Ahead
Google has now covered Googlebot’s crawl limits in documentation updates, a podcast episode, and a dedicated blog post within a two-month span. Illyes’ note that the limit may change over time suggests these figures aren’t permanent.
For sites with standard HTML pages, the 2 MB limit isn’t a concern. Pages with heavy inline content, embedded data, or oversized navigation should verify that their critical content is within the first 2 MB of the response.
WordPress 7.0, previously scheduled for an April 9th release, will be delayed in order to stabilize the Real-Time Collaboration feature and assure that the release, a major milestone, will “target extreme stability.” Much is riding on WordPress 7.0 as it will ship with features that will usher in the age of AI-driven content management systems.
Prioritization Of Stability
Matt Mullenweg, co-founder of WordPress, commenting in the official Making WordPress Slack workspace, said the release should step back from its current trajectory and prioritize stability, calling for a longer pre-release phase to get the real-time collaboration (RTC) feature working correctly. The delay is expected to last weeks, not days, and is described as a one-off deviation from WordPress’s planned date-driven schedule.
Mullenweg posted:
“Given the scope and status of 7.0, I think we should go back to beta releases, get the new tables right, lock in everything we want for 7.0, and then start RCs again. Date-driven is still our default, but for this milestone release we want to target extreme stability and exciting updates, especially as AI-accelerated development is increasing people’s expectations for software.
This is a one-off, I think for future we should get back on the scheduled train, with an aim for 4-a-year in 2027, to hopefully reflect our AI-enabled ability to move faster.”
To avoid technical compatibility issues, the project will remain in the release candidate phase, extending the testing period through additional RC builds as needed.
The proposal to return to beta releases was rejected because it would break PHP version comparison behavior, plugin update logic, and tooling that depends on standard version sequencing. Continuing with RC builds preserves compatibility while allowing more time for testing and fixes.
Real-Time Collaboration
The delay is largely due to the Real-Time Collaboration feature, which introduces new database tables and changes how WordPress handles editing sessions. Contributors identified risks related to performance, data handling, and interactions with existing systems.
A primary concern is that real-time editing currently disables persistent post caches during active sessions, a performance issue the team is working to resolve before the final release.
Database Design Raises Performance Concerns
A key part of the discussion focused on how to structure the database for Real-Time Collaboration (RTC). A proposed single RTC table would support 1. real-time editing updates and 2. synchronization. But some contributors noted that the workloads for real-time editing and synchronization are fundamentally different.
Real-time collaboration generates high-frequency, bursty writes that require low latency (meaning updates happen with very little delay).
While synchronization between environments involves slower, structured updates that may include full-table scans.
Combining both patterns within one table risks performance issues and added complexity. Contributors discussed separating these workloads into separate tables optimized for each use case, but no decision has been made.
Gap In Release Candidate Testing Raises Concern
The discussion in the WordPress Slack workspace also raised concern over whether there was enough real-world release candidate testing, and database schema changes increase the risk of failures during upgrades. The solution of using the Gutenberg plugin for testing was rejected because database changes could affect production sites and require complex migration logic. Instead, the project will use an extended RC phase to increase testing exposure and gather feedback from a wider group of users.
Versioning Constraints
The proposal to delay version 7.0 led to additional issues. PHP version comparison rules and related tooling complicated returning to beta versions. It was agreed that staying within the release candidate sequence (ergo RC1, RC2, RC3) avoids these issues while allowing continued iteration, so it was decided to continue with release candidates.
Future Release Cadence Remains
The delay is described as a temporary exception. Matt Mullenweg said the project intends to return to a regular release schedule, with a goal of delivering roughly four releases per year by 2027 as development speeds increase with AI-assisted workflows.
Implications For Developers And Users
Developers should expect continued changes to the Real-Time Collaboration feature and its supporting database structures during the extended release candidate phase. The longer testing period provides more time to identify issues before release. For site owners and hosts, the delay shows that WordPress is prioritizing stability over schedule while introducing more complex real-time and synchronization features.
Impact Of RTC On Hosting Environments
Something that wasn’t discussed but is a real issue is how real-time collaboration might affect web hosting providers. They need to test that feature to see if it introduces issues on shared hosting environments. While RTC will be shipping with the feature turned off by default, the impact of it being used by customers in a shared hosting environment is currently unknown. A spokesperson for managed WordPress hosting provider Kinsta told Search Engine Journal they are still testing. Given how the feature is still evolving, Kinsta and other web hosts will have to continue testing the upcoming WordPress release candidates.
I think most people will agree that the decision to delay the release of WordPress 7.0 is the right call.
Google’s Gary Illyes and Martin Splitt used a recent episode of the Search Off the Record podcast to discuss whether webpages are getting too large and what that means for both users and crawlers.
The conversation started with a simple question: are websites getting fat? Splitt immediately pushed back on the framing, arguing that website-level size is meaningless. Individual page size is where the discussion belongs.
What The Data Shows
Splitt cited the 2025 Web Almanac from HTTP Archive, which found that the median mobile homepage weighed 845 KB in 2015. By July, that same median page had grown to 2,362 KB. That’s roughly a 3x increase over a decade.
Both agreed the growth was expected, given the complexity of modern web applications. But the numbers still surprised them.
Splitt noted the challenge of even defining “page weight” consistently, since different people interpret the term differently depending on whether they’re thinking about raw HTML, transferred bytes, or everything a browser needs to render a page.
How Google’s Crawl Limits Fit In
Illyes discussed a 15 MB default that applies across Google’s broader crawl infrastructure, where each URL gets its own limit, and referenced resources like CSS, JavaScript, and images are fetched separately.
That’s a different number from what appears in Google’s current Googlebot documentation. Google states that Googlebot for Google Search crawls the first 2 MB of a supported file type and the first 64 MB of a PDF.
Our previous coverage broke down the documentation update that clarified these figures earlier this year. Illyes and Splitt discussed the flexibility of these limits in a previous episode, noting that internal teams can override the defaults depending on what’s being crawled.
The Structured Data Question
One of the more interesting moments came when Illyes raised the topic of structured data and page bloat. He traced it back to a statement from Google co-founder Sergey Brin, who said early in Google’s history that machines should be able to figure out everything they need from text alone.
Illyes noted that structured data exists for machines, not users, and that adding the full range of Google’s supported structured data types to a page can add weight that visitors never see. He framed it as a tension rather than offering a clear answer on whether it’s a problem.
Does It Still Matter?
Splitt said yes. He acknowledged that his home internet connection is fast enough that page weight is irrelevant in his daily experience. But he said the picture changes when traveling to areas with slower connections, and noted that metered satellite internet made him rethink how much data websites transfer.
He suggested that page size growth may have outpaced improvements in median mobile connection speeds, though he said he’d need to verify that against actual data.
Illyes referenced prior studies suggesting that faster websites tend to have better retention and conversion rates, though the episode didn’t cite specific research.
Looking Ahead
Splitt said he plans to address specific techniques for reducing page size in a future episode.
Most pages are still unlikely to hit those limits, with the Web Almanac reporting a median mobile homepage size of 2,362 KB. But the broader trend of growing page weight affects both performance and accessibility for users on slower or metered connections.
Jobs with the highest potential for AI-assisted productivity gains also face the highest projected job losses, according to a new index from Digital Planet at Tufts University’s Fletcher School.
The American AI Jobs Risk Index ranks 784 U.S. occupations, 530 metro areas, 50 states, and 20 industry sectors by vulnerability to AI-driven job loss.
All figures are model projections based on AI adoption scenarios, not actual layoffs or employment changes. The median scenario estimates 9.3 million jobs at risk, ranging from 2.7 million to 19.5 million depending on AI adoption speed.
Which Jobs Face The Highest Projected Risk
Writers and authors top the list of occupations at risk at 57%. Computer programmers and web and digital interface designers follow at 55% each. Editors are at 54%, and web developers at 46%.
Market research analysts and marketing specialists face a projected 35% job loss rate. Public relations specialists are at 37%. News analysts, reporters, and journalists face 35% risk.
Earlier analyses, such as the Anthropic Economic Index and Stanford’s “Canaries in the Coal Mine,” measured how accessible jobs are to AI. This analysis goes further by estimating how likely that exposure is to translate into projected job loss.
Augmentation & Loss Risk Go Together
Authors refer to the connection between jobs that benefit from AI-driven productivity gains and those expected to lose jobs as the “augmentation-displacement link.”
When AI increases individual workers’ efficiency, companies can produce the same output with fewer employees. This mainly affects entry-level and lower-seniority roles first, because companies can cut back on hiring rather than firing.
Writing, programming, web design, technical writing, and data analysis are where this pattern is most evident. Tasks in these fields are cognitive, language-intensive, and structured enough for large language models to manage.
By Industry
Average vulnerability across all industries is about 6%. Sectors with the highest projected job loss are Information (18%), Finance and Insurance (16%), and Professional, Scientific, and Technical Services (16%).
Software Developers, Management Analysts, and Market Research Analysts face the biggest total income losses. These three roles combine high pay with large workforces, accounting for a significant share of the projected $757 billion in total at-risk annual income.
What The Analysis Doesn’t Include
Note that job creation effects aren’t included in this version. The authors intend to add that data in future updates as they gather more evidence.
Additionally, regulatory constraints, union bargaining power, and occupational licensing requirements that could help slow job losses in some sectors are not part of this analysis. The authors emphasize that their forecasts are based on different scenarios rather than being definitive.
Why This Matters
There’s a common assumption among digital professionals that using AI to boost productivity protects their jobs. However, this data challenges that idea.
SEJ previously covered this tension in 2023 when Dr. Craig Froehle of the University of Cincinnati warned that companies not investing in employee retraining would see turnover costs double. The Tufts data puts numbers on the specific occupations where that pressure is building.
Looking Ahead
Updates to the American AI Jobs Risk Index will be made as AI capabilities and labor market conditions evolve. The authors mention that future versions will try to include job creation data along with loss estimates, providing a more complete view of AI’s overall impact on employment.
The methodology is available on the Digital Planet site, which also links to a data download page.
Google quietly updated its list of user-triggered fetchers to include a new one called Google-Agent. The new agent will be used by its Project Mariner tool that began as an AI browser agent and may now be part of a pivot to compete with OpenClaw-style personal agents.
OpenClaw
OpenClaw is a new type of personal AI agent assistant that is able to perform a wide range of tasks online. In fact, it is able to form teams with one agent as the manager (the orchestrator) handing out tasks to specialized agents in a team. These AI agents run from a laptop or desktop device as well as in hosted environments. They are model-agnostic and can connect to any cloud-based AI providers like Anthropic (Claude), Google (Gemini), and OpenAI.
Chinese AI providers like MiniMax, Moonshot AI (Kimi), Alibaba Cloud (Qwen), and DeepSeek are increasingly popular because they are significantly less expensive than mainstream American AI providers, further driving the personal AI agent boom.
The personal AI agent space is so popular and important that OpenAI hired the developer of the OpenClaw AI agent, Peter Steinberger.
Google’s Project Mariner
Project Mariner was announced in 2025 and was only available to Google AI Ultra subscribers and others who were allowed in as Google Labs testers. The initial version of Project Mariner was a browser style assistant that you could tell what to do, and it would go out onto the web and accomplish various tasks.
A video of Project Mariner in action showed it to be a fairly clunky way to navigate the web, with one tester calling it “far from perfect.”
Project Mariner Test Drive Video
Pivot To AI Agents Called LAMs
AI agents are exploding right now, largely in the developer community, especially as it intersects with the vibe-coding trend. AI is currently used for building software, WordPress plugins, creating blog posts, and monitoring and posting to social media. AI agents are essentially robot workers that can do all of that autonomously.
These kinds of user agents are becoming known as Large Action Models (LAMs). A LAM understands what a user wants accomplished, breaks the goal up into steps, clicks buttons, calls APIs, and carries out tasks autonomously or with human oversight. Unlike LLMs that basically say things, LAMs actually do things.
The imminent release of the AI-friendly WordPress 7.0 may usher in a period of rapid evolutionary change in how businesses create and manage websites, and AI agents will quite likely expand and play a big role in that.
Many of the Project Mariner staff have moved over to the Gemini Agent product, as some of the capabilities and insights from Project Mariner are moved over to other projects. Wired reported that it received confirmation, one day before Google announced the new Google-Agent crawler, that Google was moving Project Mariner staff over to its Gemini Agent product.
“A Google spokesperson confirmed the changes, but said the computer use capabilities developed under Project Mariner will be incorporated into the company’s agent strategy moving forward. Google has already folded some of these capabilities into other agent products, including the recently launched Gemini Agent, the spokesperson added.
The change comes as Google and other AI labs rush to respond to the rise of highly capable agents like OpenClaw.”
Anthropic is already ahead of Google with its announcement of Claude Cowork, a desktop interface for interacting with AI agents that makes it possible for non-coders to take advantage of AI agents.
Anthropic describes Cowork’s capabilities and purpose:
“Unlike Chat, Cowork lets Claude complete work on its own. Describe the outcome and cadence, and it takes action and keeps you informed. Come back to the result.
Claude delivers finished work instead of step-by-step updates: a formatted spreadsheet, a memo, a briefing doc. You review, refine, and decide what’s next.
Tell Claude what you want from your desktop or phone. Claude picks the fastest path: a connector for Slack, Chrome for web research, or your screen to open apps when there’s no direct integration.”
The boom in agentic AI coding has sent shockwaves through the software publishing industry based on fears that AI coding will make it easier for users to roll their own software solutions. Adobe Inc.’s stock has already lost 33% of its value over the past six months, as have many other software companies.
Screenshot Of Google Search For Adobe Inc Stock Price
For example, Mistral recently released Voxtral TTS, an inexpensive text-to-speech AI that can run on a laptop with at least 3GB of RAM, undercutting other companies offering the same service for a monthly subscription.
3gb of RAM is wild. been paying ElevenLabs $22/mo for my projects and this runs on hardware i already own. the economics of AI services are going to collapse faster than anyone’s modeling
The new Google-Agent crawler is labeled as a user-initiated crawler, meaning that the crawler is initiated by a user. The documentation for the new crawler explains:
“Google-Agent is used by agents hosted on Google infrastructure to navigate the web and perform actions upon user request (for example, Project Mariner). It uses IP ranges from user-triggered-agents.json.”
Google currently offers Gemini CLI, but it’s not a one-to-one competitor with the agent-first Claude Code, which is designed to take actions. This addition of the new Google-Agent crawler could be a small piece of a new product that is able to compete more directly with Code.
That said, Google once again finds itself racing to catch up to rapidly developing situations, and this change to the list of Google’s user-triggered fetchers is likely part of Google’s pivot to compete more robustly in the LAM space.
Google Gemini more than doubled its referral traffic to websites between November and January, according to SE Ranking data from more than 101,000 sites with Google Analytics installed.
The increase started in December, shortly after Google began rolling out Gemini 3 across its products. SE Ranking measured a 51% increase in December and a 42% increase in January, for a combined gain of about 115%.
For transparency, SE Ranking sells AI visibility tracking tools, and the data below comes from their own Google Analytics dataset.
Gemini Passes Perplexity
In January, SE Ranking’s data shows Gemini sent 29% more visitors to websites than Perplexity globally. In the U.S., the gap was wider at 41%.
Five months earlier, the positions were reversed. In August, Perplexity was sending roughly three times more referral traffic than Gemini, according to the same dataset.
ChatGPT’s Decline From Peak
ChatGPT’s referral traffic peaked in October and has fallen since then. SE Ranking measured an 8% drop in November and an 18% drop in December, with a partial recovery in January.
Even after the decline, ChatGPT still generates about 80% of all AI referral traffic to websites. ChatGPT’s lead over Gemini narrowed from roughly 22x in October to about 8x in January. That’s still a large gap.
Similarweb’s January data showed a similar pattern when measuring direct visits to chatbot sites. ChatGPT’s traffic share fell from 86% to 64% over the past year, while Gemini rose from 5% to 21 %. The two datasets measure different things, but both show the same direction.
The Gemini 3 Connection
The timing of Gemini’s traffic increase lines up with Google’s rollout of Gemini 3 models.
Google released Gemini 3 Pro on November 18, Gemini 3 Deep Think on December 4, and Gemini 3 Flash on December 17. Flash became the default model in the Gemini app and in AI Mode for Search.
Before those releases, Gemini’s referral traffic had been mostly flat for eight months. SE Ranking’s data shows it grew at roughly 4% per month from January through October. The jump to 47% monthly growth in December and January represents about a 12x acceleration from the prior pace.
AI Traffic In Context
All AI platforms combined still account for a small share of overall web traffic. SE Ranking puts the figure at about 0.24% of global internet traffic as of January, up from 0.15% in 2025.
An earlier SE Ranking report of 13,700 websites found Google generating 94% of organic traffic. ChatGPT and Perplexity were starting to show up in referral reports. The new dataset is larger at 101,574 sites across 250 markets but uses the same GA-based methodology.
Why This Matters
Two months of growth from Gemini doesn’t predict where AI referral traffic will be by year’s end. The increase from November to January is measurable and correlates with a known product launch, but it’s too early to call it a sustained pattern.
The Perplexity milestone is more concrete. Gemini may now show up as a larger referral source than Perplexity in your own analytics. That’s worth checking.
Looking Ahead
SE Ranking says it will continue monitoring AI referral traffic through 2026. Google hasn’t disclosed referral traffic figures for Gemini or AI Mode directly. The next Similarweb AI Tracker update could provide a second data point on whether Gemini’s growth continued past January.
