Seo sitemap #422
Seo sitemap #422
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Reviewer's Guide by SourceryThis PR implements SEO improvements across the application by updating the sitemap generation and metadata for various pages. The changes include refactoring sitemap generation to be more efficient, adding change frequencies and priorities for different routes, and improving page metadata with more descriptive titles and descriptions. Class diagram for updated sitemap generationclassDiagram
class Sitemap {
+sitemap() Promise<MetadataRoute.Sitemap>
}
class BlogSitemap {
+sitemap() Promise<MetadataRoute.Sitemap>
}
class AuctionSitemap {
+sitemap() Promise<MetadataRoute.Sitemap>
}
class ProjectSitemap {
+sitemap() Promise<MetadataRoute.Sitemap>
}
class PresaleSitemap {
+sitemap() Promise<MetadataRoute.Sitemap>
}
class AboutBitlauncherSitemap {
+sitemap() Promise<MetadataRoute.Sitemap>
}
class SecuritySitemap {
+sitemap() Promise<MetadataRoute.Sitemap>
}
class WhitepaperSitemap {
+sitemap() Promise<MetadataRoute.Sitemap>
}
class LegalSitemap {
+sitemap() Promise<MetadataRoute.Sitemap>
}
Sitemap <|-- BlogSitemap
Sitemap <|-- AuctionSitemap
Sitemap <|-- ProjectSitemap
Sitemap <|-- PresaleSitemap
Sitemap <|-- AboutBitlauncherSitemap
Sitemap <|-- SecuritySitemap
Sitemap <|-- WhitepaperSitemap
Sitemap <|-- LegalSitemap
note for Sitemap "Refactored to remove parameters and use static data"
note for BlogSitemap "Uses getAllArticles service"
note for AuctionSitemap "Uses generateStaticParams service"
note for ProjectSitemap "Uses generateStaticParams service"
note for PresaleSitemap "Uses generateStaticParams service"
Class diagram for updated metadata generationclassDiagram
class ProjectPage {
+generateMetadata(params: ProjectPageProps) Metadata
}
class PresalePage {
+generateMetadata(params: ProjectPageProps) Metadata
}
class BlogPage {
+generateMetadata(params: BlogPageProps) Metadata
}
ProjectPage <|-- PresalePage
ProjectPage <|-- BlogPage
note for ProjectPage "Generates metadata using project details"
note for PresalePage "Generates metadata with presale-specific details"
note for BlogPage "Generates metadata using page SEO text"
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
WalkthroughThe pull request introduces significant modifications across multiple files, primarily focusing on the Changes
Possibly related PRs
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
🔇 Additional comments (1)apps/web/tsconfig.json (1)
The ES6 target is a reasonable choice for modern web applications and aligns well with the project's modernization efforts. However, ensure this meets your browser compatibility requirements. Let's verify the browser requirements and any existing documentation: Consider documenting minimum supported browser versions if not already specified. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @luighis - I've reviewed your changes - here's some feedback:
Overall Comments:
- Remove the console.log statement in blog/page.tsx as it appears to be debug code
- The terms page metadata incorrectly shows 'Privacy Policy' as the title - this should be updated to 'Terms of Service' or similar
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
🧹 Outside diff range and nitpick comments (23)
apps/web/app/(routes)/[lang]/whitepaper/page.tsx (1)
13-14: LGTM! SEO-friendly metadata updates.The metadata changes improve SEO by providing more descriptive and comprehensive content. The title and description are well-crafted and align with SEO best practices.
Consider adding more metadata properties to further enhance SEO:
export const metadata: Metadata = { title: 'Comprehensive Whitepaper', description: 'Explore the detailed whitepaper of Bitlauncher, covering all aspects of our innovative platform and technology.', + openGraph: { + title: 'Comprehensive Whitepaper | Bitlauncher', + description: 'Explore the detailed whitepaper of Bitlauncher, covering all aspects of our innovative platform and technology.', + type: 'article', + }, + twitter: { + card: 'summary_large_image', + title: 'Comprehensive Whitepaper | Bitlauncher', + description: 'Explore the detailed whitepaper of Bitlauncher, covering all aspects of our innovative platform and technology.', + } }apps/web/app/(routes)/[lang]/blog/sitemap.ts (2)
4-4: Consider removing async keywordThe function is marked as async but doesn't contain any asynchronous operations. Consider removing the async keyword since it adds unnecessary Promise wrapping.
-export default async function sitemap(): Promise<MetadataRoute.Sitemap> { +export default function sitemap(): MetadataRoute.Sitemap {
Line range hint
5-20: Consider using a static lastModified dateUsing
new Date()for lastModified will generate a different timestamp on each request, which could impact caching efficiency. Consider using a static date that represents when the blog content was last updated.{ url: `https://${process.env.NEXT_PUBLIC_APP_URL}/blog`, - lastModified: new Date(), + lastModified: new Date('2024-01-01'), // Update this when blog content changes priority: 0.9,apps/web/app/(routes)/[lang]/about/about-bitlauncher/sitemap.ts (1)
Line range hint
7-9: Validate environment variable and consider static lastModified date.Two suggestions for improvement:
- Add validation for
NEXT_PUBLIC_APP_URLto prevent runtime errors- Consider using a static lastModified date that reflects actual content updates instead of the current date
Apply this diff:
+if (!process.env.NEXT_PUBLIC_APP_URL) { + throw new Error('NEXT_PUBLIC_APP_URL environment variable is not defined'); +} + +// Use a static date that reflects the last content update +const LAST_MODIFIED = new Date('2024-01-01'); + return [ { url: `https://${process.env.NEXT_PUBLIC_APP_URL}/about/about-bitlauncher`, - lastModified: new Date(), + lastModified: LAST_MODIFIED, priority: 0.6,apps/web/app/(routes)/[lang]/[project]/sitemap.ts (2)
Line range hint
8-22: Consider environment variable handling and URL security
- Using
process.env.NEXT_PUBLIC_APP_URLin static generation might cause issues if the environment variable is not available during build time.- The URL construction should include input validation for
item.projectto prevent potential security issues.Consider adding validation and fallback:
+ const baseUrl = process.env.NEXT_PUBLIC_APP_URL || 'example.com' + const safeProjectId = encodeURIComponent(item.project) - url: `https://${process.env.NEXT_PUBLIC_APP_URL}/${item.project}`, + url: `https://${baseUrl}/${safeProjectId}`,
13-20: Enhance language alternate handlingThe current implementation of language alternates is good, but consider adding hreflang annotations in your page metadata as well for better SEO.
Consider adding a helper function for consistent URL generation across the application:
function generateLocalizedUrl(lang: string, project: string, baseUrl: string) { const safeProject = encodeURIComponent(project); return `https://${baseUrl}/${lang}/${safeProject}`; }apps/web/app/(routes)/[lang]/[project]/auction/sitemap.ts (1)
11-11: Consider making changeFrequency configurableThe hardcoded 'yearly' change frequency might not be suitable for all auction pages. Consider making this configurable based on the project type or auction status.
- changeFrequency: 'yearly', + changeFrequency: getChangeFrequency(item.project), // Add a function to determine frequency based on project typeapps/web/app/(routes)/[lang]/blog/[category]/[slug]/sitemap.ts (1)
9-23: Optimize URL generation and improve code maintainability.The current implementation has several areas for improvement:
- Repeated URL base construction
- Nested mapping operations that could be simplified
- Direct environment variable usage
Consider refactoring to this more maintainable structure:
+const BASE_URL = `https://${process.env.NEXT_PUBLIC_APP_URL}` + +const createArticleUrl = (lang: string, category: string, slug: string) => + `${BASE_URL}${lang ? `/${lang}` : ''}/blog/${category}/${slug}` + export default async function sitemap(): Promise<MetadataRoute.Sitemap> { const articles = await getAllArticles() if (!articles) return [] return articles.flatMap((item) => item.articles.map((article) => ({ - url: `https://${process.env.NEXT_PUBLIC_APP_URL}/blog/${item.category}/${article.slug}`, + url: createArticleUrl('', item.category, article.slug), lastModified: article._publishedAt, priority: 0.6, alternates: { languages: Object.fromEntries( AVAILABLE_LANGS.map((lang) => [ lang, - `https://${process.env.NEXT_PUBLIC_APP_URL}/${lang}/blog/${item.category}/${article.slug}`, + createArticleUrl(lang, item.category, article.slug), ]), ), }, })), ) }apps/web/app/(routes)/[lang]/blog/[category]/sitemap.ts (3)
7-11: Add error logging for better debuggingThe current error handling silently returns an empty array, which could hide potential issues. Consider adding error logging for better observability.
try { sections = await getArticleSections('en') } catch (error) { + console.error('Failed to fetch article sections:', error) return [] }
Line range hint
15-26: Consider using actual content update datesCurrently,
lastModifieduses the current date, which might not reflect when the content was last updated. Consider using the actual last modification date from the article sections data.return categories.map((category) => ({ url: `https://${process.env.NEXT_PUBLIC_APP_URL}/blog/${category}`, - lastModified: new Date(), + lastModified: section.updatedAt || new Date(), priority: 0.7, alternates: {
Line range hint
1-26: SEO structure looks solidThe sitemap implementation follows SEO best practices:
- Proper URL structure
- Language alternates support
- Reasonable priority values
- Error resilience
Consider adding
changefreqto provide search engines with more crawling guidance.apps/web/app/(routes)/[lang]/[project]/presale/sitemap.ts (1)
11-24: Consider adding environment variable validation and URL utility functionThe sitemap generation logic could benefit from some improvements:
- Add validation for the
NEXT_PUBLIC_APP_URLenvironment variable- Consider extracting URL construction to a reusable utility function
- Consider making
changeFrequencyandpriorityconfigurable based on project requirementsHere's a suggested refactor:
+ const validateAppUrl = (url: string | undefined): string => { + if (!url) throw new Error('NEXT_PUBLIC_APP_URL is not defined'); + return url; + } + + const generateProjectUrl = (appUrl: string, lang: string, project: string, path: string) => + `https://${appUrl}/${lang}/${project}/${path}`; export default async function sitemap(): Promise<MetadataRoute.Sitemap> { const projects = await generateStaticParams() + const appUrl = validateAppUrl(process.env.NEXT_PUBLIC_APP_URL); return projects.map((item) => ({ - url: `https://${process.env.NEXT_PUBLIC_APP_URL}/${item.project}/presale`, + url: generateProjectUrl(appUrl, '', item.project, 'presale'), lastModified: new Date(), changeFrequency: 'yearly', priority: 0.9, alternates: { languages: Object.fromEntries( AVAILABLE_LANGS.map((lang) => [ lang, - `https://${process.env.NEXT_PUBLIC_APP_URL}/${lang}/${item.project}/presale`, + generateProjectUrl(appUrl, lang, item.project, 'presale'), ]), ), }, })) }apps/web/app/sitemap.ts (1)
29-46: Consider enhancing sitemap entries with dynamic lastModified dates.Instead of using
new Date()which sets the modification date to when the sitemap is generated, consider tracking actual content updates for more accurate lastModified dates. This helps search engines better understand your content freshness.Example implementation:
import { getFileLastModifiedDate } from '../utils/file-utils' // Inside sitemap function { url: 'https://bitlauncher.ai/whitepaper', lastModified: await getFileLastModifiedDate('whitepaper'), changeFrequency: 'monthly', priority: 0.7, }apps/web/app/(routes)/[lang]/blog/page.tsx (1)
37-37: Remove debug console.log statementDebug logging statements should be removed before deployment to production.
- console.log("🚀 ~ pageSeo:", pageSeo)apps/web/app/(routes)/[lang]/wallet/page.tsx (1)
Line range hint
52-67: Consider TypeScript improvements and text centralizationTwo suggestions for improvement:
- Add TypeScript type definition for the component:
-function BalancesCard() { +function BalancesCard(): React.ReactElement {
- Consider centralizing the description text to avoid duplication with metadata:
+const WALLET_DESCRIPTIONS = { + title: 'Wallet Balances', + description: 'Your balances on the Bitcash | Bitlauncher ecosystem. Connect your Bitcash and EVM wallets' +} as const; export const metadata: Metadata = { - title: 'Wallet Balances', - description: - 'Your balances on the Bitcash | Bitlauncher ecosystem. Connect your Bitcash and EVM wallets', + title: WALLET_DESCRIPTIONS.title, + description: WALLET_DESCRIPTIONS.description, } function BalancesCard(): React.ReactElement { return ( <Card> <CardHeader> - <CardTitle>Wallet Balances</CardTitle> + <CardTitle>{WALLET_DESCRIPTIONS.title}</CardTitle> <CardDescription> - Your balances on the Bitcash | Bitlauncher ecosystem. Connect your - Bitcash and EVM wallets. + {WALLET_DESCRIPTIONS.description} </CardDescription> </CardHeader>apps/web/app/(routes)/[lang]/about/about-bitlauncher/page.tsx (1)
Line range hint
11-16: Fix inconsistent language handlingThe component receives a dynamic language parameter but passes a hardcoded 'en' to the child component. This breaks internationalization support and ignores the user's language preference.
Apply this fix:
<AboutBitlauncherPageLanding content={content} params={{ - lang: 'en', + lang: params.lang, }} />apps/web/app/(routes)/[lang]/sitemap.ts (2)
21-76: Consider extracting common URL construction logicThe sitemap entries follow a consistent pattern but contain duplicated code. Consider refactoring to improve maintainability.
+ const createSitemapEntry = ( + path: string, + changeFrequency: 'yearly' | 'monthly', + priority: number + ) => ({ + url: `https://${process.env.NEXT_PUBLIC_APP_URL}${path}`, + lastModified: new Date(), + changeFrequency, + priority, + alternates: { + languages: Object.fromEntries( + AVAILABLE_LANGS.map((lang) => [ + lang, + `https://${process.env.NEXT_PUBLIC_APP_URL}/${lang}${path}`, + ]), + ), + }, + }); export default async function sitemap(): Promise<MetadataRoute.Sitemap> { return [ - { - url: `https://${process.env.NEXT_PUBLIC_APP_URL}`, - lastModified: new Date(), - changeFrequency: 'yearly', - priority: 1, - alternates: { - languages: Object.fromEntries( - AVAILABLE_LANGS.map((lang) => [ - lang, - `https://${process.env.NEXT_PUBLIC_APP_URL}/${lang}`, - ]), - ), - }, - }, + createSitemapEntry('', 'yearly', 1), + createSitemapEntry('/blog', 'monthly', 0.8), + createSitemapEntry('/whitepaper', 'yearly', 0.6), + createSitemapEntry('/learn/security', 'yearly', 0.6), + createSitemapEntry('/about/about-bitlauncher', 'yearly', 0.6), ]; }
23-23: Consider using specific lastModified datesUsing
new Date()for all entries means they'll show the generation time rather than actual content modification times. Consider:
- Using specific dates for static content
- Fetching actual last modification dates for dynamic content (like blog)
- lastModified: new Date(), + lastModified: new Date('2024-01-01'), // Or fetch from content metadataAlso applies to: 37-37, 51-51, 65-65
apps/web/app/(routes)/[lang]/[project]/presale/page.tsx (2)
Line range hint
29-30: Consider optimizing the database queriesThe TODO comment indicates that multiple separate queries could be optimized into a single query. This could improve page load performance.
Would you like me to help create a more efficient query that combines these operations?
Line range hint
39-39: Implement auction logic or remove placeholderThe code contains a hardcoded
falsevalue with a TODO comment about implementing auction logic. This could lead to confusion about the actual state of the auction.Would you like me to help implement the auction logic or create a GitHub issue to track this task?
apps/web/app/(routes)/[lang]/[project]/page.tsx (3)
Line range hint
18-22: Add error handling for async operationsThe component performs multiple async operations (
getDictionary,getProjectBySlug,createSupabaseServerClient,getPresaleData) without proper error handling. Consider wrapping these in try-catch blocks to gracefully handle potential failures.- const dict = await getDictionary(params.lang) - const project = await getProjectBySlug(params.project, dict) - if (!project || !project.content) redirect('/') + try { + const dict = await getDictionary(params.lang) + const project = await getProjectBySlug(params.project, dict) + if (!project || !project.content) redirect('/') + } catch (error) { + console.error('Failed to fetch project data:', error) + redirect('/') + }
Line range hint
25-28: TODO comments need addressingThere are multiple TODOs related to auction logic. These placeholders could lead to unexpected behavior.
Would you like me to help create a GitHub issue to track the implementation of the auction logic? This should include:
- Implementing auction status check
- Setting actual auction start/end dates
- Adding auction data fetching similar to presale
Line range hint
103-112: Remove or implement commented codeThere's a commented-out code block that appears to be an alternative implementation for rendering content. This should either be implemented or removed to maintain code clarity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (18)
apps/web/app/(routes)/[lang]/[project]/auction/sitemap.ts(1 hunks)apps/web/app/(routes)/[lang]/[project]/page.tsx(1 hunks)apps/web/app/(routes)/[lang]/[project]/presale/page.tsx(1 hunks)apps/web/app/(routes)/[lang]/[project]/presale/sitemap.ts(1 hunks)apps/web/app/(routes)/[lang]/[project]/sitemap.ts(1 hunks)apps/web/app/(routes)/[lang]/about/about-bitlauncher/page.tsx(1 hunks)apps/web/app/(routes)/[lang]/about/about-bitlauncher/sitemap.ts(1 hunks)apps/web/app/(routes)/[lang]/blog/[category]/[slug]/sitemap.ts(1 hunks)apps/web/app/(routes)/[lang]/blog/[category]/sitemap.ts(1 hunks)apps/web/app/(routes)/[lang]/blog/page.tsx(1 hunks)apps/web/app/(routes)/[lang]/blog/sitemap.ts(1 hunks)apps/web/app/(routes)/[lang]/learn/security/page.tsx(1 hunks)apps/web/app/(routes)/[lang]/legal/privacy/page.tsx(1 hunks)apps/web/app/(routes)/[lang]/legal/terms/page.tsx(1 hunks)apps/web/app/(routes)/[lang]/sitemap.ts(2 hunks)apps/web/app/(routes)/[lang]/wallet/page.tsx(1 hunks)apps/web/app/(routes)/[lang]/whitepaper/page.tsx(1 hunks)apps/web/app/sitemap.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- apps/web/app/(routes)/[lang]/legal/terms/page.tsx
🔇 Additional comments (22)
apps/web/app/(routes)/[lang]/about/about-bitlauncher/sitemap.ts (2)
4-4: LGTM! Function signature simplified.
The removal of the unused params parameter simplifies the interface while maintaining the same functionality.
Line range hint 10-17: Verify language alternates configuration.
The language alternates implementation looks correct, but let's verify the configuration across other routes for consistency.
✅ Verification successful
The previous search might have failed because the pattern was too specific. Let's examine the actual content of the sitemap files to verify the language alternates implementation and URL structure consistency.
Language alternates configuration is consistent across routes
After reviewing all sitemap files, the language alternates implementation is consistent across the codebase:
- All routes correctly import and use
AVAILABLE_LANGSfrom@/lib/config - The URL structure consistently follows the pattern
https://${process.env.NEXT_PUBLIC_APP_URL}/${lang}/[route] - All implementations use
Object.fromEntrieswithAVAILABLE_LANGS.map()to generate the language alternates - The only exception is the root
sitemap.tswhich intentionally doesn't include alternates as it serves as the base sitemap
Note: There is one minor inconsistency in legal/terms/sitemap.ts where the URL uses learn/terms instead of legal/terms in the alternates, but this is outside the scope of the current review.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check language alternates implementation across sitemap files
# Expected: Similar pattern using AVAILABLE_LANGS and consistent URL structure
# Find all sitemap.ts files
echo "Checking sitemap implementations across routes..."
rg -l 'sitemap.*MetadataRoute.Sitemap' --type ts
# Check for language alternates implementation
echo "\nChecking language alternates implementation..."
rg -A 5 'alternates.*languages.*Object.fromEntries' --type ts
Length of output: 788
Script:
#!/bin/bash
# Let's try a different approach to check language alternates implementation
# Search for alternates configuration in sitemap files
# First, let's check the content of sitemap files
for file in $(fd sitemap.ts); do
echo "=== Content of $file ==="
cat "$file"
echo -e "\n"
done
Length of output: 16218
apps/web/app/(routes)/[lang]/legal/privacy/page.tsx (1)
16-20: Verify metadata consistency across pages.
Let's ensure this metadata structure aligns with other pages in the application.
apps/web/app/(routes)/[lang]/[project]/sitemap.ts (2)
5-5: LGTM! Function signature simplified appropriately.
The removal of the unused params parameter aligns with Next.js best practices for static sitemap generation.
6-6: Verify the shape of data returned by generateStaticParams
Ensure that generateStaticParams() consistently returns objects with the expected project property.
✅ Verification successful
Based on the comprehensive analysis of the codebase, I can now generate the final response:
The shape of data returned by generateStaticParams is consistent and well-defined
The implementation in [project]/page.tsx shows that generateStaticParams() returns an array of objects with the expected shape { lang, project }. This is consistently used across sitemap generation in multiple files, including presale and auction routes. The data comes from a well-structured projects array defined in the codebase that ensures data consistency.
Key validations:
- The project data is strongly typed with
ProjectPageParamsinterface - The function properly merges localized content with base project data
- The returned objects always contain the required
projectproperty - The implementation is used consistently across the application
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the shape of data returned by generateStaticParams
# Look for the implementation and usage of generateStaticParams
# Find the implementation
echo "Searching for generateStaticParams implementation:"
ast-grep --pattern 'export async function generateStaticParams() {
$$$
}'
# Find other usages to verify consistency
echo "Searching for other usages of item.project in sitemaps:"
rg -A 2 'item\.project.*sitemap'
Length of output: 801
Script:
#!/bin/bash
# Let's check the actual implementation in the sitemap.ts and page.ts files
# First, find the sitemap.ts file
echo "Searching for sitemap.ts implementation:"
fd "sitemap.ts" --exec cat {}
echo -e "\nSearching for page.ts implementation:"
fd "page.ts" --type f --exec sh -c 'echo "=== $1 ==="; cat "$1"' sh {}
# Look for any project-related types or interfaces
echo -e "\nSearching for project-related types:"
rg -A 5 "type.*Project|interface.*Project"
Length of output: 60113
Script:
#!/bin/bash
# Let's check the implementation of getProjects and getProjectBySlug to understand the data shape
echo "Searching for getProjects implementation:"
ast-grep --pattern 'export function getProjects($$$) {
$$$
}'
echo -e "\nSearching for getProjectBySlug implementation:"
ast-grep --pattern 'export function getProjectBySlug($$$) {
$$$
}'
# Also check the actual projects data
echo -e "\nSearching for project data in dictionaries:"
fd "projects.ts" --exec cat {}
Length of output: 95591
apps/web/app/(routes)/[lang]/[project]/auction/sitemap.ts (3)
1-5: LGTM! Clean function signature simplification.
The removal of unused params parameter and the addition of generateStaticParams import improves code clarity.
6-6: Verify the data structure from generateStaticParams
Let's ensure that the returned data structure contains the required project field.
✅ Verification successful
Looking at the results, I can see that the generateStaticParams function imported from '../page' (apps/web/app/(routes)/[lang]/[project]/page.tsx) returns an array of ProjectPageParams which includes both lang and project fields. This is confirmed by the implementation:
export async function generateStaticParams(): Promise<ProjectPageParams[]> {
// ...
project.slug ? { lang, project: project.slug } : null,The data structure is compatible with the sitemap usage since it returns objects containing the project field that's used in the URL construction:
url: `https://${process.env.NEXT_PUBLIC_APP_URL}/${item.project}/auction`Data structure compatibility verified
The generateStaticParams function returns the expected data structure with the required project field needed for sitemap generation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the structure of generateStaticParams implementation
# Expected: Should see a function that returns an array of objects with a 'project' field
# Search for the generateStaticParams implementation
ast-grep --pattern 'export async function generateStaticParams() {
$$$
}'
# Backup: If not found with exact match, search for any occurrence
rg -A 10 "generateStaticParams"
Length of output: 10317
8-22: Verify environment variable availability in production
Ensure that NEXT_PUBLIC_APP_URL is properly set in all deployment environments.
✅ Verification successful
The environment variable NEXT_PUBLIC_APP_URL is used consistently and safely
Based on the comprehensive analysis of the codebase, the usage of NEXT_PUBLIC_APP_URL is appropriate and follows Next.js best practices:
- The
NEXT_PUBLIC_prefix indicates it's intentionally exposed to the client-side, which is correct for URL construction in sitemap generation - The variable is used consistently across multiple sitemap files in a standardized way
- The monorepo structure shows proper environment configuration management through the app-env package
- The project documentation indicates proper environment setup for different deployment stages (prod, test, dev)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for environment variable usage in deployment configurations
# Expected: Should find environment variable definitions
# Search for environment variable definitions
rg "NEXT_PUBLIC_APP_URL" -g "*.env*"
rg "NEXT_PUBLIC_APP_URL" -g "*.yaml" -g "*.yml"
Length of output: 84
Script:
#!/bin/bash
# Let's check for the environment variable usage in a broader context
# including Next.js configuration files and deployment-related files
# Check for environment variable in various config files
rg "NEXT_PUBLIC_APP_URL"
# Also check for any URL construction patterns in the codebase
rg "process\.env\.NEXT_PUBLIC_APP_URL"
# Look for environment setup patterns in next config
fd "next.config" --exec cat {}
Length of output: 12443
Script:
#!/bin/bash
# Let's check for environment variable setup in deployment files and example env files
# Look for example env files or environment setup documentation
fd -g "*.env.example" --exec cat {}
fd -g "*.env.template" --exec cat {}
# Check for deployment configuration files
fd "deploy" -e yml -e yaml --exec cat {}
fd "deployment" -e yml -e yaml --exec cat {}
# Check for documentation about environment setup
fd "README" --exec cat {}
Length of output: 29500
apps/web/app/(routes)/[lang]/blog/[category]/[slug]/sitemap.ts (2)
1-3: LGTM! Import statements are well-structured.
The imports are correctly organized and the new getAllArticles service aligns with the simplified sitemap generation approach.
12-13: Verify the impact of priority value change.
The priority value has been increased from 0.5 to 0.6. While this is valid, ensure this aligns with your SEO strategy for blog articles relative to other pages.
✅ Verification successful
Let me gather more context about where these different priorities are used to better understand the SEO hierarchy.
Priority value of 0.6 for blog articles aligns with the site's SEO hierarchy
The priority value of 0.6 for blog articles is consistent with the site's SEO strategy, where:
- Main project pages and blog index have highest priority (0.9)
- Whitepaper and main blog section have high priority (0.8)
- Blog articles (0.6) are appropriately prioritized below main content but above utility pages like wallet (0.3)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check other sitemap priorities in the project
rg -g "sitemap.ts" "priority: \d+\.\d+" --no-filename | sort | uniq -c
Length of output: 269
Script:
#!/bin/bash
# Find all sitemap.ts files and show their paths along with priorities
rg -g "sitemap.ts" "priority: \d+\.\d+" -B 5 --with-filename
Length of output: 9864
apps/web/app/(routes)/[lang]/blog/[category]/sitemap.ts (1)
13-14: LGTM!
The slug extraction is clean and straightforward.
apps/web/app/(routes)/[lang]/[project]/presale/sitemap.ts (2)
Line range hint 1-8: LGTM! Clean function signature update
The removal of the params parameter and switch to generateStaticParams() aligns well with Next.js patterns and simplifies the function signature while maintaining proper typing.
9-9: Verify the implementation of generateStaticParams
Let's ensure that the imported generateStaticParams function properly returns the expected project data structure.
✅ Verification successful
Implementation of generateStaticParams is properly structured and type-safe
The function is well-implemented in the parent page.tsx:
- Returns Promise<ProjectPageParams[]>
- Properly handles localization by mapping through locales
- Uses getProjects() with dictionary support
- Includes null safety with type filtering
- The sitemap correctly uses the returned data to generate URLs with proper language alternates
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the implementation of generateStaticParams in the parent page.ts
# Check the implementation of generateStaticParams
ast-grep --pattern 'export async function generateStaticParams() {
$$$
}'
# Check the return type/structure
rg -A 10 "generateStaticParams" "../page.ts"
Length of output: 628
Script:
#!/bin/bash
# Let's try to find the correct path for the page.ts file and check its implementation
fd "page.ts" apps/web/app/\(routes\)/\[lang\]/\[project\]/presale/
# Check for any imports of generateStaticParams in the sitemap.ts
rg -A 5 "import.*generateStaticParams" apps/web/app/\(routes\)/\[lang\]/\[project\]/presale/sitemap.ts
# Look for the implementation in the project directory
ast-grep --pattern 'export async function generateStaticParams() {
$$$
}' --path apps/web/app/\(routes\)/\[lang\]/\[project\]
Length of output: 725
Script:
#!/bin/bash
# Let's check the implementation in the parent directory's page file
rg -A 10 "generateStaticParams" apps/web/app/\(routes\)/\[lang\]/\[project\]/page.tsx
# Also check the actual implementation using ast-grep
ast-grep --pattern 'export async function generateStaticParams() {
$$$
}' apps/web/app/\(routes\)/\[lang\]/\[project\]/page.tsx
# Let's also see how the data is used in sitemap.ts
rg -A 10 "projects.map" apps/web/app/\(routes\)/\[lang\]/\[project\]/presale/sitemap.ts
Length of output: 1259
apps/web/app/sitemap.ts (2)
29-46: LGTM! Well-structured sitemap entries with appropriate priorities.
The new entries for whitepaper and legal pages are well-organized with consistent formatting and appropriate priority values that align with the existing hierarchy.
Line range hint 1-48: Verify sitemap configuration and search engine registration.
Ensure that:
- The sitemap is properly generated as XML in production
- The sitemap is registered in robots.txt
- The sitemap is submitted to major search engines
✅ Verification successful
Based on the results from the shell scripts, I can now provide a final response:
Sitemap configuration is properly implemented with recommended practices.
The verification shows:
- Sitemap is correctly registered in robots.txt with
Sitemap: https://bitlauncher.ai/sitemap.xml - Next.js dynamic sitemap generation is properly implemented using the MetadataRoute API
- Multiple sitemap files exist for different sections, following a modular approach
- The sitemap includes proper changeFrequency and priority settings
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if robots.txt exists and contains sitemap reference
fd -t f "robots.txt" -x cat {} | grep -i "sitemap"
# Check for next.js sitemap configuration in next.config.js
fd -t f "next.config.js" -x cat {} | grep -i "sitemap"
Length of output: 149
Script:
#!/bin/bash
# Check if there are any other sitemap-related files or configurations
fd -t f -e xml -e ts -e js -e json | grep -i "sitemap"
# Look for any sitemap-related code in the codebase
rg -i "sitemap" -g "!{node_modules,dist,build}/*" -A 2 -B 2
# Check package.json for sitemap-related dependencies
fd "package.json" -x cat {} | jq '.dependencies,.devDependencies' | grep -i "sitemap"
Length of output: 131987
apps/web/app/(routes)/[lang]/learn/security/page.tsx (1)
34-36: SEO improvements look good, verify metadata length constraints.
The updated title and description are more descriptive and engaging, which should improve SEO performance. However, let's verify they meet search engine constraints:
- Title (55 chars): ✓ Within Google's 60-character limit
- Description (123 chars): ✓ Within Google's 155-160 character limit
✅ Verification successful
SEO metadata structure and length constraints are consistent across pages
The metadata changes for the security page align well with the site-wide SEO patterns:
- Title (55 chars) follows the same descriptive pattern seen in other pages like "About Bitlauncher" and "Whitepaper"
- Description (123 chars) maintains consistent length and style with other pages
- Both fields are well within Google's recommended limits (60 chars for title, 155-160 for description)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent metadata patterns across pages
# Look for other metadata exports to ensure consistent SEO structure
# Search for metadata exports in page components
rg -g '*.tsx' -g '*.ts' --multiline --multiline-dotall 'export const metadata: Metadata = \{.*?\}' -A 5
Length of output: 4399
apps/web/app/(routes)/[lang]/about/about-bitlauncher/page.tsx (1)
65-68: LGTM! Well-structured metadata for SEO
The updated metadata follows SEO best practices with:
- Descriptive title that includes relevant keywords
- Clear and action-oriented description that explains the value proposition
apps/web/app/(routes)/[lang]/sitemap.ts (2)
4-4: LGTM! Function signature simplified
The removal of the unused params parameter improves code clarity while maintaining the same functionality.
Line range hint 9-19: Verify environment variable availability
While the addition of changeFrequency is good for SEO, let's ensure the environment variable is properly configured.
✅ Verification successful
Based on the gathered information, I can now provide the final response:
Environment variable setup follows Next.js best practices
The codebase follows proper environment variable handling through Vercel's deployment workflow:
- The README explicitly documents the setup process using
vercel env pull NEXT_PUBLIC_APP_URLis a public environment variable (prefixed with NEXT_PUBLIC_) as required for client-side usage- Environment variables are managed through Vercel's environment management system
The sitemap usage of this variable is safe as it:
- Uses the standard Next.js environment variable pattern
- Is properly prefixed for client exposure
- Has documented setup instructions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if NEXT_PUBLIC_APP_URL is defined in environment files
echo "Checking for NEXT_PUBLIC_APP_URL in environment files..."
fd -t f -e env . | xargs grep "NEXT_PUBLIC_APP_URL"
Length of output: 174
Script:
#!/bin/bash
# Let's check for environment variable usage and configuration patterns
# First, check for any .env.example or similar template files
fd -t f -g '*.env*' .
# Then, let's look for the actual usage of this environment variable in the codebase
rg "NEXT_PUBLIC_APP_URL" -A 2 -B 2
# Also check package.json for any scripts or configuration that might set this variable
fd -t f -g 'package.json' . | xargs cat
Length of output: 32046
Script:
#!/bin/bash
# Let's check for Next.js configuration files that might contain environment variable setup
fd -t f -g 'next.config.*' apps/web/
# Also check for any documentation about environment setup
fd -t f -g 'README*' apps/web/
# And check for environment variable validation or configuration in the codebase
rg -A 3 -B 3 "env\.(NEXT_PUBLIC_APP_URL|validateEnv)" apps/web/
Length of output: 19862
Script:
#!/bin/bash
# Let's check the contents of next.config.js and README.md for environment setup instructions
echo "=== next.config.js contents ==="
cat apps/web/next.config.js
echo -e "\n=== README.md contents ==="
cat apps/web/README.md
# Also check for any environment validation in the codebase
rg -A 3 -B 3 "validateEnv|env\." apps/web/app/env.ts apps/web/app/config.ts apps/web/app/lib/env.ts 2>/dev/null
Length of output: 6231
apps/web/app/(routes)/[lang]/[project]/presale/page.tsx (1)
85-90: Verify metadata implementation consistency
Let's ensure this metadata implementation pattern is consistent with other pages in the application.
✅ Verification successful
Metadata implementation is consistent across the application
The verification shows that the metadata implementation follows consistent patterns throughout the application:
- Project pages use dynamic metadata based on project data:
- Main project page uses project title and pitch
- Presale page uses project name with "Presale" prefix
- Other pages use static metadata with descriptive titles and descriptions
- Root layout (
[lang]/layout.tsx) properly sets up metadata templates and defaults - Blog section correctly handles dynamic metadata from CMS data
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other generateMetadata implementations
ast-grep --pattern 'export async function generateMetadata({ params }: $_) {
$$$
}'
# Search for other metadata patterns
rg -A 5 'title:|description:' 'apps/web/app'
Length of output: 8960
apps/web/app/(routes)/[lang]/[project]/page.tsx (2)
Line range hint 147-166: LGTM! Well-implemented static params generation
The implementation efficiently handles parallel processing of locales and properly filters out invalid params. The type safety is well maintained.
Line range hint 168-171: LGTM! Well-implemented dynamic import
The dynamic import implementation follows Next.js best practices with proper loading state handling.
There was a problem hiding this comment.
Very good changes! I noticed a few improvements that we can make. I added additional comments to the related feedbacks. all of them were given by coderabbitai. Next time make sure to review them (mark as resolved if a feedback doesn't apply) and make conversations to move forward.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
apps/web/app/(routes)/[lang]/blog/[category]/sitemap.ts (1)
9-11: LGTM! Consider using Set for uniquenessThe current implementation correctly extracts unique categories. However, for better performance with larger datasets, consider using Set:
- const categoryUrls = articles - .map((article) => article.category) - .filter((category, index, self) => self.indexOf(category) === index) + const categoryUrls = [...new Set(articles.map((article) => article.category))]
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
apps/web/app/(routes)/[lang]/blog/[category]/sitemap.ts(1 hunks)
🧰 Additional context used
📓 Learnings (1)
apps/web/app/(routes)/[lang]/blog/[category]/sitemap.ts (1)
Learnt from: AndlerRL
PR: bitcashorg/smartsale#422
File: apps/web/app/(routes)/[lang]/blog/[category]/sitemap.ts:5-5
Timestamp: 2024-11-28T07:24:24.716Z
Learning: In the Next.js application for the 'smartsale' project, when generating sitemaps (e.g., in `sitemap.ts` files), we should include the language routes for multilingual support, even if middleware handles redirects to language-specific paths.
🔇 Additional comments (3)
apps/web/app/(routes)/[lang]/blog/[category]/sitemap.ts (3)
6-7: LGTM! Good error handling
The null check with early return is a good practice for handling the case when no articles are found.
2-2: Verify the impact of removing props parameter
The function no longer receives props, which previously might have contained language information. While this simplifies the function, ensure that getAllArticles correctly handles multilingual content retrieval.
Also applies to: 5-5
✅ Verification successful
Let me check the implementation of the DatoCMS query to verify language handling.
Language handling is hardcoded in getAllArticles
The removal of props parameter is not a concern as the getAllArticles function is explicitly designed to fetch English content with English fallback (locale: 'en', fallbackLocales: ['en']). This is consistent with the codebase's approach, and the function's implementation shows it's intentionally handling English-only content.
- The hardcoded language setting is located in the DatoCMS query configuration in
apps/web/services/datocms/datocms-all-articles.service.ts - The function is used consistently across multiple sitemap generators and blog pages
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if getAllArticles handles language parameters
# Expected: Function should support multilingual content
# Check the implementation of getAllArticles
ast-grep --pattern 'export $_ getAllArticles($_) {
$$$
}'
# Check usage patterns
rg "getAllArticles" -A 2
Length of output: 2353
Script:
#!/bin/bash
# Check the DatoCMS query implementation for language handling
cat apps/web/services/datocms/datocms-all-articles.service.ts
Length of output: 2664
Line range hint 13-24: Verify the base URL structure
The implementation correctly generates language alternates, but let's verify the base URL structure:
- Base URL omits language prefix:
https://${process.env.NEXT_PUBLIC_APP_URL}/blog/${category} - Alternates include language prefix:
/${lang}/blog/${category}
This structure assumes middleware handles language redirects, which aligns with the retrieved learning about including language routes for multilingual support.
✅ Verification successful
URL structure is correctly implemented
The implementation is verified to be correct based on the following evidence:
- The middleware (
apps/web/middleware.ts) handles language-based routing by redirecting non-language-prefixed URLs to their language-prefixed versions. - The sitemap URL structure is consistent across the application, as seen in multiple sitemap files using the same pattern.
- The base URL without language prefix is correct as it allows search engines to discover the default route, while the alternates properly include language prefixes for multilingual SEO.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify URL structure consistency across the application
# Expected: Similar URL patterns in related components
# Check URL patterns in blog-related components
fd "page.tsx|layout.tsx" --type f | grep -i "blog" | xargs rg "href.*blog.*category"
# Check middleware handling
fd "middleware.ts" --type f | xargs rg "redirect.*lang"
Length of output: 140
Script:
#!/bin/bash
# Let's try a broader search for URL patterns and middleware handling
# Check for blog-related URL patterns
rg -A 2 "blog.*category" --type ts
# Check for middleware or routing configuration
fd "middleware|route" --type f | xargs rg -l "language|locale|lang"
# Check for any URL generation patterns
rg "NEXT_PUBLIC_APP_URL" --type ts
Length of output: 11171
Script:
#!/bin/bash
# Let's check the middleware implementation for language handling
# Check middleware content
cat apps/web/middleware.ts
# Check for any Next.js configuration related to i18n
fd "next.config" --type f | xargs cat
Length of output: 4875
There was a problem hiding this comment.
LGTM! We need to test the SEO and sitemap once it is deployed to development env. Merging!
@AnoukRImola -- please run a web scrapping test for BL pages: About, Whitepaper, Home, Bitlauncher Project Page and Blog main page, categories and topics and check for the sitemap differences between production env for SEO improvements. Additionally, to check the opengraph for Blog articles (between topics and categories), categories and topics, we need to make sure that the CMS content is appearing as expected.
This reverts commit 2358f2f.
Summary by Sourcery
Enhance the SEO capabilities of the website by implementing a detailed sitemap for multiple sections, improving metadata for better search engine visibility, and refactoring sitemap generation for efficiency.
New Features:
Enhancements:
Documentation:
Summary by CodeRabbit
Release Notes
New Features
Improvements
changeFrequencyproperty to sitemap entries for better search engine optimization.Bug Fixes